pub struct FetchOk {
pub end_of_track: u8,
pub end_group: VarInt,
pub end_object: VarInt,
pub parameters: Vec<KeyValuePair>,
pub track_properties: Vec<KeyValuePair>,
}Expand description
FETCH_OK (0x18). end_of_track is uint8.
Byte-identical to draft-19; the field that changed meaning is
FetchOk::end_object.
Fields§
§end_of_track: u8§end_group: VarInt§end_object: VarIntThe Object ID of the last Object the response covers, inclusive.
This is the silent off-by-one of the revision, and it is absent from draft-20’s own change log. Draft-19 Section 10.13 defined the pair as “the end of the range covered by the FETCH response, using the same encoding as the FETCH request End Location (the last Object, plus 1; or 0 to indicate the entire Group)”. Draft-20 Section 10.14 drops that parenthesis entirely, and Sections 5.1.2 and 10.13 both say the Location filter “specifies an inclusive range of Locations”.
So both draft-19 conventions are gone: there is no plus one, and an Object of 0 now means object 0 rather than the whole group. The bytes are identical between the two drafts and the meaning is not, and nothing on the wire distinguishes them — an encoder ported forward with its arithmetic intact fetches one object too many, and one whose end lands on object 0 fetches a single object where it used to fetch a group.
Ambiguous, and the draft leaves it so. When the request’s filter
omitted EndObject, so the
filter meant “all objects in the End Group”, Section 10.14 does not say
what to report — and with the 0-means-whole-group encoding gone there
is no way left to spell it. The same applies to a relative start. The
reading this codec’s corpus takes, and the only sane one, is the Object
ID of the last Object actually covered; the draft does not say so, and
nothing here can enforce it, because resolving it needs the track rather
than the frame.
parameters: Vec<KeyValuePair>§track_properties: Vec<KeyValuePair>