Jakub Narebski <jnareb@xxxxxxxxx> wrote: > 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. -- 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