On Fri, 29 Aug 2008, Shawn O. Pearce wrote: > 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. [...] > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
