Re: Comments pack protocol description in "Git Community Book" (second round)

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jun 7, 2009, 20:13 UTC
Message-ID: <20090607201324.GB16497@spearce.org>
In-Reply-To: <200906071021.08922.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> wrote:

Show 13 quoted lines

> In description of sideband:
> 
> >  When a sideband is used, 2 means "progress messages, most likely
> >  suitable for stderr". 1 means "pack data". 3 means "fatal error
> >  message, and we're dead now".  No other channels are used or valid.
> 
> it is true that no other channels are used, but it is not true that 
> other channels are invalid. If they are not supported by client, there 
> are simply dropped. This opens possibility of future extension. I guess 
> that channel 0 is invalid, because it would be understood as _input_ 
> channel (for sending data from client to server), though.
> 
> Please correct me if I am wrong here...

An implementation reading a muxed stream SHOULD fail fast if it encounters a channel number it doesn't understand.

JGit already fails fast with an error if it gets anything not in 1-3. C Git already fails fast with an error as well.

An implementation writing a muxed stream shouldn't produce a channel number unless it knows the reader can support it.

To add a new channel number to the supported set, a new capability should be introduced to the protocol, and enabled if both sides have agreed to support it.

Currently, stream 0 and stream 4-255 are undefined. That is, any new capability could claim that stream and start to use it, if it needed to.

I think the primary Git contributors would prefer to see new channels
in the 4-255 range, as then 0 can continue to stay invalid... aka
"not true" in C.  Like in the pack type codes, we might want to save
0 for the day when all 1-255 are filled and we need to expand the
channel number range into 2 bytes.  But even then, we could just
do a new side-band-64kv2 capability or something.  :-)

-- 
Shawn.