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