On 03/02, Junio C Hamano wrote: > Brandon Williams <bmw...@google.com> writes: > > > + Capabilities > > +~~~~~~~~~~~~~~ > > + > > +There are two different types of capabilities: normal capabilities, > > +which can be used to to convey information or alter the behavior of a > > +request, and commands, which are the core actions that a client wants to > > +perform (fetch, push, etc). > > + > > +All commands must only last a single round and be stateless from the > > +perspective of the server side. All state MUST be retained and managed > > +by the client process. This permits simple round-robin load-balancing > > +on the server side, without needing to worry about state management. > > + > > +Clients MUST NOT require state management on the server side in order to > > +function correctly. > > This somehow feels a bit too HTTP centric worldview that potentially > may penalize those who do not mind stateful services.
It's meant to be that way so that we don't run into the same issue we have with the current HTTP transport. Though I've decided to loosen this slightly by making protocol v2 stateless by default unless a capability is advertised and requested by the client indicating that state can be maintained by the server. That leaves the door open for adding state later for transports which have full-duplex connections while still requiring that stateless is designed first. I'm kind of hoping we never need to add state to the protocol because hopefully we can figure out how to improve negotiation as a whole. > > > + agent > > +------- > > + > > +The server can advertise the `agent` capability with a value `X` (in the > > +form `agent=X`) to notify the client that the server is running version > > +`X`. The client may optionally send its own agent string by including > > +the `agent` capability with a value `Y` (in the form `agent=Y`) in its > > +request to the server (but it MUST NOT do so if the server did not > > +advertise the agent capability). > > Are there different degrees of permissiveness between "The server > CAN" and "The client MAY" above, or is the above paragraph merely > being fuzzy? I don't think so? I believe I ripped this from the existing description of the agent capability from the current protocol. -- Brandon Williams
