Advertise hg client capabilities to hg server
anton.gogolev at gmail.com
Fri Feb 7 03:41:39 CST 2014
On 31.01.2014, at 9:22, Matt Mackall <mpm at selenic.com> wrote:
> On Tue, 2014-01-28 at 12:37 +0400, Anton Gogolev wrote:
>> I'm entertaining the idea of how useful would it be for hg server to know
>> a thing or two about the client that is connecting to it.
> To date, we've intentionally kept negotiation with the server very
> one-sided. The server reports what it's capable of, the client makes all
> the decisions. This is especially useful in situations like hgweb.cgi
> where the server retains no state between requests. It also means
> there's no question of a client/server mismatch as clients have to be
> capable of talking to servers with zero capabilities.
I might be missing something, but I don't see where exactly in the exchange protocol does server need to maintain any state whatoever. All the information is sent on every request.
>> How can this be useful, you ask? For one, this would allow server to
>> enforce a client to enable specific extensions (like projrc, which is
>> useful in a corporate environment) or warn about outdated version or
>> possible problems with repository on a local machine (when cloning a
>> repository created on a case-sensitive file system to a Windows machine).
>> This might introduce slight security problems with exposing a list of
>> enabled extensions to the server, but this can be solved with a client-
>> side configuration knob, which would default to existing, "anonymous"
>> What do you think of that?
> It's not a completely awful idea but I think it can still be done in a
> server-tells-client fashion. For instance, the server can advertise that
> it requires-extensions.hgeol or recommends-extensions.projrc and the
> client can pass that info along to the user.
For one, server already decides a bunch of things based on what a client sends it - ACLs, for instance.
Second, there will be no way for server to actively _enforce_ some particular requirement.
> Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel