bzr.dev <-> bzr.dev network api break
John Arbash Meinel
john at arbash-meinel.com
Mon Jan 21 15:47:29 GMT 2008
Andrew Bennetts wrote:
> Andrew Bennetts wrote:
> [...]
>> Perhaps we should just do this bump now, there's a couple of things accumulating
>> that we could fix in a new protocol version:
>>
>> * reliably consume bodies of unrecognised requests (and responses)
>> * an explicit, clean way for a server to signal to the client that a request
>> verb is unrecognised
>> * sending client version information
>
> Oh, and something else that would be nice:
>
> * allowing 8-bit clean request/response args (i.e. provide a way to encode
> 0x01 and 0x0a).
>
> -Andrew.
Having encountered the bug with Repository.stream_revisions.... where
arg parsing is slow, I would actually push for moving more stuff into
the "body" of the request.
Then you could turn them into Length + Data like we do for bulk data.
Probably what I would prefer is something like:
REQUEST ::= REQUEST_NAME REQUEST_ARGS REQUEST_DATA
REQUEST_ARGS ::= num_args total_arg_length (REQUEST_ARG)*
REQUEST_ARG ::= length 8bit_data
REQUEST_DATA ::= (CHUNK_DATA | SIMPLE_DATA)
SIMPLE_DATA ::= 'simple' data_length 8bit_data
CHUNK_DATA ::= 'chunked' (CHUNK)*
CHUNK ::= chunk_length 8bit_data
I would even go so far as to make fields like num_args and *length
32-bit big-endian (un?)signed integers. Maybe not, but I do find having
to "read a little bit, oops not done, read a bit more, nope still not
done" to be a poor way to parse streams.
If we do stick with ascii numbers, I think adding terminators is
actually a good thing. As it lets us read a minimum of 2 bytes at a time :).
John
=:->
More information about the bazaar
mailing list