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

Hi,

On Tue, 10 Mar 2009, Shawn O. Pearce wrote:

Johannes Sixt [off-list ref] wrote:

quoted

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.

Fair enough, the tie-breaker hath spoken.

Ciao,
Dscho