Hi, On Tue, 10 Mar 2009, Shawn O. Pearce wrote: > Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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 -- 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
