class StreamOutputFormat

Returns whether no field is set.

Returns whether the table references unknown fields.

Return a builder that by defaults allocates of an arena.

Return a builder that relies on explicitly allocating |fidl::ObjectView|s.

A client is permitted to ignore an OnOutputFormat() message even with

buffer_constraints_action_required true if the client knows the server

has already been told to discard the remainder of the stream with the

same stream_lifetime_ordinal or if this stream_lifetime_ordinal field is

set to 0. The server is required to re-send needed output config via

OnOutputConstraints() with new stream_lifetime_ordinal and

buffer_constraints_action_required true, if the most recent completed

server-side output config isn't what the server wants/needs yet for the

new stream.

The server is required to send an OnOutputFormat() before the first

output packet of a stream.

If format_details.format_details_version_ordinal changes, the client

should inspect the new format details and determine if it must adjust to

the new format. The server guarantees that if the format has changed, then

format_details.format_details_version_ordinal will change, but a change

to format_details.format_details_version_ordinal does not guarantee that

the format details actually changed. Servers are strongly encouraged to

not change format_details.format_details_version_ordinal other than

before the first output data of a stream unless there is a real

mid-stream format change in the stream. Unnecessary mid-stream format

changes can cause simpler clients that have no need to handle mid-stream

format changes to just close the channel. Format changes before the

first output data of a stream are not "mid-stream" in this context -

those can be useful for stream format detection / setup reasons.

Note that in case output buffers don't really need to be re-configured

despite a format change, a server is encouraged, but not required, to

set buffer_constraints_action_required false on the message that conveys

the new format details. Simpler servers may just treat the whole output

situation as one big thing and demand output buffer reconfiguration on

any change in the output situation.

A client may or may not actually handle a new buffer_constraints with

buffer_constraints_action_required false, but the client should always

track the latest format_details.

An updated format_details is ordered with respect to emitted output

packets, and applies to all subsequent packets until the next

format_details with larger version_ordinal. A simple client that does

not intend to handle mid-stream format changes should still keep track

of the most recently received format_details until the first output

packet arrives, then lock down the format details, handle those format

details, and verify that any

format_details.format_details_version_ordinal received from the server

is the same as the locked-down format_details, until the client is done

with the stream. Even such a simple client must tolerate

format_details.format_details_version_ordinal changing multiple times

before the start of data output from a stream (any stream - the first

stream or a subsequent stream). This allows a stream processor to

request that output buffers and output format be configured

speculatively, and for the output config to be optionally adjusted by

the server before the first data output from a stream after the server

knows everything it needs to know to fully establish the initial output

format details. This simplifies stream processor server implementation,

and allows a clever stream processor server to guess it's output config

for lower latency before any input data, while still being able to fix

the output config (including format details) if the guess turns out to

be wrong.

Whether the format_details.format_details_version_ordinal will actually

change mid-stream is a per-stream-processor and per-stream detail that

is not specified in comments here, and in most cases also depends on

whether the format changes on the input to the stream processor.

Probably it'll be fairly common for a client to use a format which

technically supports mid-stream format change, but the client happens to

know that none of the streams the client intends to process will ever

have a mid-stream format change.