From: Johannes Sixt <j.sixt@viscovery•net>
To: Johannes Schindelin <Johannes.Schindelin@gmx•de>
Cc: git@vger•kernel.org, gitster@pobox•com,
Peter Harris <git@peter•is-a-geek.org>,
Sebastian Schuberth <sschuberth@gmail•com>,
Nicolas Pitre <nico@cam•org>
Subject: Re: [PATCH/RFC] recv_sideband: Band #2 always goes to stderr
Date: Tue, 10 Mar 2009 15:26:23 +0100 [thread overview]
Message-ID: <49B6788F.2080609@viscovery.net> (raw)
In-Reply-To: <alpine.DEB.1.00.0903101343530.14295@intel-tinevez-2-302>
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
next prev parent reply other threads:[~2009-03-10 14:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1236639280u.git.johannes.schindelin@gmx.de>
2009-03-10 0:41 ` [PATCH] winansi: support ESC [ K (erase in line) Johannes Schindelin
2009-03-10 7:15 ` Johannes Sixt
2009-03-10 7:30 ` [PATCH/RFC] recv_sideband: Band #2 always goes to stderr Johannes Sixt
2009-03-10 10:56 ` Johannes Schindelin
2009-03-10 11:11 ` Johannes Sixt
2009-03-10 11:17 ` Johannes Sixt
2009-03-10 11:39 ` Johannes Schindelin
2009-03-10 12:14 ` Johannes Sixt
2009-03-10 12:52 ` Johannes Schindelin
2009-03-10 14:26 ` Johannes Sixt [this message]
2009-03-10 14:38 ` Shawn O. Pearce
2009-03-10 14:46 ` Johannes Schindelin
2009-03-10 23:59 ` Junio C Hamano
2009-03-10 14:46 ` Shawn O. Pearce
2009-03-10 15:02 ` Johannes Sixt
2009-03-10 15:07 ` Johannes Schindelin
2009-03-10 15:14 ` Johannes Sixt
2009-03-10 17:35 ` Nicolas Pitre
2009-03-10 16:35 ` Jay Soffian
2009-03-10 17:37 ` Nicolas Pitre
2009-03-10 21:54 ` [PATCH 1/2] recv_sideband: Bands #2 and #3 always go " Johannes Sixt
2009-03-10 21:58 ` [PATCH 2/2] winansi: support ESC [ K (erase in line) Johannes Sixt
2009-03-11 10:22 ` Johannes Schindelin
2009-03-10 11:31 ` [PATCH] " Johannes Schindelin
2009-03-10 12:29 ` Peter Harris
2009-03-10 12:54 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49B6788F.2080609@viscovery.net \
--to=j.sixt@viscovery$(echo .)net \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=git@peter$(echo .)is-a-geek.org \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=nico@cam$(echo .)org \
--cc=sschuberth@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox