cmdserver protocol questions

Kevin Bullock kbullock+mercurial at ringworld.org
Thu Jun 30 12:41:28 CDT 2011


On Jun 30, 2011, at 3:08 AM, Martin Geisler wrote:

> Hi guys,
> 
> Jan is writing a Java library for the cmdserver and he had a number of
> questions for me about the protocol. I've tried to sum them up below:
> 
> * Right now, you must always run the cmdserver in an existing repository
>  even if you want to run a commands.norepo command like 'hg init'.
> 
>  Perhaps we should have both 'hg serve' that does what it used to do
>  and a new 'hg cmdserver' command -- the latter should be in
>  commands.optionalrepo whereas the first cannot be there.

Can we do that, given the fact that the command server is due to appear in 1.9 tomorrow?

> * Parsing of server's hello block: it would have been nicer if this had
>  been a standard format such as JSON -- now everyone has to implement
>  the parsing by themselves.
> 
>  This is of course not difficult in itself, but now implementors must
>  decide if whitespace should be trimmed from each line? It is also not
>  clearly specified what a "field" is -- is it something that matches
>  "[a-z]+:" or can there be other characters in a field? The safe choice
>  must be to split (once!) on ':', but will all implementations do this?
> 
>  Field names will presumably always be in ASCII?

Specifying RFC822-style headers would fix this without introducing anything so cumbersome as JSON. Please let's not have a block-structured format for something that can easily be line-structured.

> * Termination of server's hello block: how many 'o' channel writes can a
>  client expect? The example shows several writes on the 'o' channel,
>  but in practice it seems that there is only one and I think this was
>  also mentioned somewhere on this mailinglist?

I thought we'd established that the hello block will always be sent in a single chunk? <http://www.selenic.com/hg/rev/c19de7f32961>?

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock



More information about the Mercurial-devel mailing list