bzr.dev <-> bzr.dev network api break

[Andrew Bennetts]

John Arbash Meinel wrote:
> Andrew Bennetts wrote:
[...]
>> 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:

Well, we can do length-prefixing of arguments without moving them into the body.
Same benefit to parsing, no change to semantics...

[I also seem to recall that we can fix the pessmistic reading from pipes without
changing the protocol, although I'd have to dig through the list archives for
the details.  But in general I do like length-prefixing.]

[...]
> 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.

A tradeoff there is that you introduce finite limits to lengths; in theory, you
could send many gigabytes in a single body (or chunk) over the smart protocol at
the moment...

Of course, we're a long way from having that be practical, and even if were
practical that doesn't mean it's a good idea.

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

Heh.

-Andrew.