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

[Junio C Hamano <gitster@pobox.com>]

Duy Nguyen <pclouds@gmail.com> writes:

> Step 1 then should be identifying these wrongdoings and assumptions.
>
> We can really go wild with these capabilities. The only thing that
> can't be changed is perhaps sending the first ref. I don't know
> whether we can accept a dummy first ref... After that point, you can
> turn the protocol upside down because both client and server know what
> it would be.

Yes, exactly.  To up/down/side-grade from v1 is technically
possible, but being technically possible is different from being
sensible.  The capability-based sidegrade does not solve the problem
when the problem to be solved is that the server side needs to spend
a lot of cycles and the network needs to carry megabytes of data
before capability exchange happens.  Yes, the newer server and the
newer client can notice that the counterparty is new and start
talking in new protocol (which may or may not benefit from already
knowing the result of ref advertisement), but by the time that
happens, the resource has already been spent and wasted.

I do not think v1 can be fixed by "send one ref with capability,
newer client may respond immediately so we can stop enumerating
remaining refs and older one will get stuck so we can have a timeout
to see if the connection is from the newer one, and send the rest
for the older client", because anything that involves such a timeout
would not reliably work over WAN.

> You realize you're advertising v2 as a new capability, right? Instead
> of defining v2 feature set then advertise v2, people could simply add
> new features directly. I don't see v2 (at least with these patches)
> adds any value.

I agree with the value assessment of these patches 98%, but these
bits can be taken as the "we have v2 server availble for you on the
side, by the way" hint you mentioned in the older thread, I think.

> And we already does that, except that we don't state what version (as
> a number) exactly, but what feature that version supports. The focus
> should be the new protocol at daemon.c and maybe remote-curl.c where
> we do know the current protocol is not flexible enough.

The "first" thing the client tells the server is what service it
requests.  A request over git:// protocol is read by "git daemon" to
choose which service to run, and it is read directly by the login
shell if it comes over ssh:// protocol.

There is nothing that prevents us from defining that service to be a
generic "git service", not "upload-pack", "archive", "receive-pack".
And the early protocol exchange, once "git service" is spawned, with
the client can be "what real services does the server end support?"
capability list responded with "wow, you are new enough to support
the 'trickle-pack' service---please connect me to it" request.