Duy Nguyen <pclouds@xxxxxxxxx> 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. -- 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