From: Johannes Schindelin Date: Tue, 10 Mar 2009 14:46:23 GMT Subject: Re: [PATCH/RFC] recv_sideband: Band #2 always goes to stderr Message-ID: In-Reply-To: <20090310143851.GP11989@spearce.org> Hi, On Tue, 10 Mar 2009, Shawn O. Pearce wrote: > Johannes Sixt 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. Fair enough, the tie-breaker hath spoken. Ciao, Dscho