On Sun, Mar 1, 2015 at 3:41 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> - 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?
>> 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..
> - 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
--
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