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

[Duy Nguyen <pclouds@gmail.com>]

On Thu, Feb 26, 2015 at 2:31 PM, Stefan Beller <sbeller@google.com> wrote:
> On Wed, Feb 25, 2015 at 10:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Duy Nguyen <pclouds@gmail.com> writes:
>>
>>> On Wed, Feb 25, 2015 at 6:37 AM, Stefan Beller <sbeller@google.com> wrote:
>>>> I can understand, that we maybe want to just provide one generic
>>>> "version 2" of the protocol which is an allrounder not doing bad in
>>>> all of these aspects, but I can see usecases of having the desire to
>>>> replace the wire protocol by your own implementation. To do so
>>>> we could try to offer an API which makes implementing a new
>>>> protocol somewhat easy. The current state of affairs is not providing
>>>> this flexibility.
>>>
>>> I think we are quite flexible after initial ref advertisement.
>>
>> Yes, that is exactly where my "I am not convinced" comes from.
>>
>
> We are not. (not really at least). We can tune some parameters or
> change the behavior slightly,
> but we cannot fix core assumptions made when creating v2 protocol.
> This you can see when when talking about v1 as well: we cannot fix any
> wrongdoings of v1 now by adding another capability.

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.

> So from my point
> of view we don't waste resources when having an advertisement of
> possible protocols instead of a boolean flag indicating v2 is
> supported. There is really not much overhead in coding nor bytes
> exchanged on the wire, so why not accept stuff that comes for free
> (nearly) ?

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 mean how do we know all the core assumptions made for v2 hold in the
> future? We don't. That's why I'd propose a plain and easy exchange at
> first stating the version to talk.

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.
-- 
Duy