Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider format for streamed types #28

Open
mp911de opened this issue Jul 12, 2019 · 1 comment
Open

Reconsider format for streamed types #28

mp911de opened this issue Jul 12, 2019 · 1 comment

Comments

@mp911de
Copy link

mp911de commented Jul 12, 2019

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).

@antirez
Copy link
Owner

antirez commented Jul 12, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants