You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Streamed types are modeled with an unknown length. However, the individual chunk lengths are known. Defining an EOF marker and stream-parsing the EOF marker introduces a certain degree of complexity to clients.
Why we don't stick to a pattern such as partial length-prefixed chunks? Each chunk is prefixed with a length indicator (similar to strings) and a negative length value would serve for the EOF marker.
?10<CR><LF>
<10 bytes of data><CR><LF>
?400<CR><LF>
<400 bytes of data><CR><LF>
?-1<CR><LF> <----- EOF marker
(using ? here as there was no other free character as a prefix for a stream response type).
The text was updated successfully, but these errors were encountered:
Hello @mp911de, yep we are going in the direction you said, I had no time to update the spec but is similar to what you suggested. I'll try to update it shortly.
Streamed types are modeled with an unknown length. However, the individual chunk lengths are known. Defining an EOF marker and stream-parsing the EOF marker introduces a certain degree of complexity to clients.
Why we don't stick to a pattern such as partial length-prefixed chunks? Each chunk is prefixed with a length indicator (similar to strings) and a negative length value would serve for the EOF marker.
(using
?
here as there was no other free character as a prefix for a stream response type).The text was updated successfully, but these errors were encountered: