Re: [PATCH v3 12/35] serve: introduce git-serve
From: Jonathan Nieder <hidden>
Date: 2018-03-05 21:37:00
Hi, Jeff King wrote:
I agree that would be a lot more pleasant for adding protocol features. But I just worry that the stateful protocols get a lot less efficient. I'm having trouble coming up with an easy reproduction, but my recollection is that http has some nasty corner cases, because each round of "have" lines sent to the server has to summarize the previous conversation. So you can get a case where the client's requests keep getting bigger and bigger during the negotiation (and eventually getting large enough to cause problems).
That's not so much a corner case as just how negotiation works over http. We want to do better (e.g. see [1]) but that's a bigger change than the initial protocol v2. As Brandon explained it to me, we really do want to use stateless-rpc semantics by default, since that's just better for maintainability. Instead of having two protocols, one that is sane and one that struggles to hoist that into stateless-rpc, there would be one stateless baseline plus capabilities to make use of state. For example, it would be nice to have a capability to remember negotiation state between rounds, to get around exactly the problem you're describing when using a stateful protocol. Stateless backends would just not advertise such a capability. But doing that without [1] still sort of feels like a cop-out. If we can get a reasonable baseline using ideas like [1] and then have a capability to keep server-side state as icing on the cake instead of having a negotiation process that only really makes sense when you have server-side state, then that would be even better.
If anything, I wish we could push the http protocol in a more stateful direction with something like websockets. But I suspect that's an unrealistic dream, just because not everybody's http setup (proxies, etc) will be able to handle that.
Agreed. I think we have to continue to deal with stateless-rpc semantics, at least for the near future. Jonathan [1] https://public-inbox.org/git/20180227054638.GB65699@aiede.svl.corp.google.com/