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

[Johannes Sixt <j.sixt@viscovery.net>]

Johannes Schindelin schrieb:
> Hi,
> 
> On Tue, 10 Mar 2009, Johannes Sixt wrote:
> 
>> Johannes Schindelin schrieb:
>>> FWIW GitTorrent may be implemented as part of git-daemon, if Sam's 
>>> ideas become reality.  And then, sideband transport is _the_ means to 
>>> do asyncrounous communication while pushing bytes.
>> I do not see how recv_sideband() in its current form could be helpful 
>> here (assuming that you really are thinking of sending binary data over 
>> band #2).
> 
> I think it is a safe bet that the side band would be a good way to 
> exchange updates to the mirror list as well as the refs list.

Binary or not - the purpose and suitability of the sideband *protocol* for
this task are undisputed.

But you don't want to have "remote:" thrown in at seemingly random places
in the demultiplexed stream that comes fromt he current implementation of
recv_sideband().

>>> On Tue, 10 Mar 2009, Johannes Sixt wrote:
>>>> And it really is: Did you notice that stuff that recv_sideband sends 
>>>> over the channel named 'err' (before my patch) has "remote: " 
>>>> prepended on every line? That's certainly not an implementation that 
>>>> you want if you send binary data over that band!
>>> Yes, that is unfortunate, but can be fixed easily.
>> I don't believe this. Every treatment of "remote: " that you take away
>> from recv_sideband() you must insert somewhere else. Perhaps easy, but
>> certainly not as trivial as my patch.
> 
> AFAICT it would be a matter of
> 
> 	unsigned pf = isatty(err) ? strlen(PREFIX) : 0;

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().

>> Just a reminder: You proposed to override write() on Windows in a 
>> non-trivial way, and we are discussing the topic above because I think 
>> that is not a good idea. The reasons are:
>>
>> - write() is a fundamental operation, and we should not mess with it out 
>>   of caution.
> 
> But we do not mess with it!  We ask explicitely if we are talking about a 
> tty.

With reference to Peter's reply, I'm not the only one who gets nervous if
write() is replaced in a non-trivial way.

After all, you are sneaking the high-level concept "terminal emulation"
into the low-level write() function.

>> - Your proposal is not a catch-all. For example, combine-diff.c uses 
>>   puts() in dump_quoted_path(). If your goal was to not touch code 
>>   outside of compat/ then you need to override at least puts(), too.
> 
>>From compat/mingw.h:
> 
> -- snip --
> /*
>  * ANSI emulation wrappers
>  */
> 
> int winansi_fputs(const char *str, FILE *stream);
> [...]
> #define fputs winansi_fputs
> -- snap --
> 
> ... added in c09df8a, SOBbed by yourself ;-)

My point was that you cannot get away without modifying code outside of
compat/ (if that was your motivation to override write()). I don't care
whether we change this instance to fputs() or fprintf(). But we already
*have* something, and don't need *yet another* override.

>> - All code that writes ANSI escapes should use fprintf() anyway.  
>>   (Currently that is not the case, but all cases I'm aware of can be 
>>   fixed trivially.)
> 
> I disagree that all ANSI escapes have to go through fprintf().  Sometimes 
> you have a buffer, and I do not like doing extra work with %.*s there.

But on the other hand you risk breaking write() semantics and give us a
colorful mix of concepts.

I don't insist in that ANSI escapes must go through fprintf(), but they
should really not go through a level that is lower than stdio. Basic file
IO should really not be muddied with terminal emulation.

> BTW I hope that you are not annoyed by the discussion; I think it is 
> necessary and important.  I am certainly not married to my current POV; so 
> far, I am still in favor of it, though.

I'm absolutely not annoyed. And I am as married to my POV as you are to
yours. ;) In this case we perhaps need a tie-breaker.

-- Hannes