Re: [RFC/PATCH 0/3] protocol v2

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 1, 2015, 11:32 UTC
Message-ID: <CACsJy8DKbfU7TBHhT5_qpL0QM3zbxkaF+B4x3hQDpomQ_9OSEg@mail.gmail.com>
In-Reply-To: <xmqq1tl9gld9.fsf@gitster.dls.corp.google.com>

On Sun, Mar 1, 2015 at 3:41 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

>>  - Because the protocol exchange starts by the server side
>>    advertising all its refs, even when the fetcher is interested in
>>    a single ref, the initial overhead is nontrivial, especially when
>>    you are doing a small incremental update.  The worst case is an
>>    auto-builder that polls every five minutes, even when there is no
>>    new commits to be fetched [*3*].

Maybe you can elaborate about how to handle states X, Y... in your footnote 3. I just don't see how it's actually implemented. Or is it optional feature that will be provided (via hooks, maybe) by admin? Do we need to worry about load balancers? Is it meant to address the excessive state transfer due to stateless nature of smart-http?

Show 6 quoted lines

>> I'd like to see a new protocol that lets us overcome the above
>> limitations (did I miss others? I am sure people can help here)
>> sometime this year.
>
> Unfortunately, nobody seems to want to help us by responding to "did
> I miss others?" RFH, here are a few more from me.

Heh.. I did think about it, but I didn't see anything worth mentioning..

Show 11 quoted lines

>  - The semantics of the side-bands are unclear.
>
>    - Is band #2 meant only for progress output (I think the current
>      protocol handlers assume that and unconditionally squelch it
>      under --quiet)?  Do we rather want a dedicated "progress" and
>      "error message" sidebands instead?
>
>    - Is band #2 meant for human consumption, or do we expect the
>      other end to interpret and act on it?  If the former, would it
>      make sense to send locale information from the client side and
>      ask the server side to produce its output with _("message")?

No producing _(...) is a bad idea. First the client has to verify placeholders and stuff, we can't just feed data from server straight to printf(). Producing _() could complicate server code a lot. And I don't like the idea of using client .po files to translate server strings. There could be custom strings added by admin, which are not available in client .po. String translation should happen at server side.

If we want error messages to be handled by machine as well, just add a result code at the beginning, like ftp, http, ... do. Hmm.. this could be the reason to separate progress and error messages.

-- 
Duy