Re: Git-aware HTTP transport

From: Nicolas Pitre <nico@cam.org>
Date: Aug 29, 2008, 19:55 UTC
Message-ID: <alpine.LFD.1.10.0808291546570.1624@xanadu.home>
In-Reply-To: <20080829173954.GG7403@spearce.org>

On Fri, 29 Aug 2008, Shawn O. Pearce wrote:

Show 7 quoted lines

> Yet another draft follows.  I believe that I have covered all
> comments with this draft.  But I welcome any additional ones,
> as thus far it has been a very constructive process.
> 
> The updated protocol looks more like the current native protocol
> does.  This should make it easier to reuse code between the two
> protocol implementations.

[...]

Show 14 quoted lines

> pkt-line Format
> ---------------
> 
> Much of the payload is described around pkt-lines.
> 
> A pkt-line is a variable length binary string.  The first four bytes
> of the line indicates the total length of the line, in hexadecimal.
> The total length includes the 4 bytes used to denote the length.  A
> line is usually terminated by an LF, which must be included in the
> total length if present.
> 
> Binary data is permitted within a pkt-line so implementors should
> ensure their pkt-line parsing/formatting routines are 8-bit clean.
> The maximum length of a pkt-line's data is 65532 bytes (65536 - 4).

Shouldn't that be 65531, since you cannot represent 65536 with 4 hex digits?

> 	C: 001bcapability include-tag
> 	C: 0019capability thin-pack
> 	....

[...]

>      The "capability" command requests a single protocol feature
>      to be enabled by the server.  Typically these are used to
>      describe aspects of the pack that will be returned.  See
>      below for more details on the current capabilities.

Why not having all capabilities listed at once on a single line instead? That's more or less what the current protocol does already.

Nicolas