On Thu, Feb 26, 2015 at 2:31 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Wed, Feb 25, 2015 at 10:04 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Duy Nguyen <pclouds@xxxxxxxxx> writes: >> >>> On Wed, Feb 25, 2015 at 6:37 AM, Stefan Beller <sbeller@xxxxxxxxxx> 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 -- 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