Re: [PATCH/RFC] recv_sideband: Band #2 always goes to stderr

> Johannes Sixt <j.sixt@viscovery.net> wrote:
> > But don't you see that are mixing a high-level concept of "terminal" 
> > into the low-level function that you want it to be? In its current 
> > form, recv_sideband() is *not* a low-level utility, it's already at a 
> > high level that knows about the line-oriented nature of band #2. What 
> > you need for GitTorrent is a different function that *only* 
> > demultiplexes the sideband protocol data into different streams 
> > without munging them. That's a totally different function that *maybe* 
> > can share some code with the current recv_sideband().
> 
> ACK.
> 
> The definition of the streams in the current sideband protocol are 
> rather well defined for the one protocol that uses it, 
> fetch-pack/receive-pack:
> 
>   stream #1:  pack data
>   stream #2:  stderr messages, progress, meant for tty
>   stream #3:  oh-sh*t abort message, remote is dead, goodbye!
> 
> The stream number is encoded as a byte.  Anyone trying to reuse the 
> sideband protocol within the fetch-pack/receive-pack protocol to carry 
> *extra* data should use new channel numbers.  We have another 252 
> remaining.  I don't think we're lacking on description space.