cmdserver protocol questions

Martin Geisler mg at aragost.com
Fri Jul 1 10:20:07 CDT 2011


Idan Kamara <idankk86 at gmail.com> writes:

> On Fri, Jul 1, 2011 at 1:02 PM, Martin Geisler <mg at aragost.com> wrote:
>>
>> Idan Kamara <idankk86 at gmail.com> writes:
>>
>> Hi Idan,
>>
>> Let me start by saying that I love that we now have this cmdserver
>> component. I think it will be quite important in the future,
>> especially when we get it hooked up to a TCP port so that people can
>> use it remotely. Is making the cmdserver listen on a port part of
>> your plan?
>
> Initially it was TCP, but Matt explained the issues involved with a
> remote approach:

I agree that this is non-trivial to implement in a secure fashion.

>> Without a norepo command the interface becomes non-uniform. Our
>> current thinking is that we'll create an empty dummy repository in
>> order to run commands like
>>
>>  hg clone http://somewhere/remote local
>>
>> It would be much better if we could just launch 'hg cmdserver' and that
>> would then be a repository-less command server.
>
> I agree that it's an inconvenience that it doesn't work for norepo
> commands, we can probably add that functionality after 1.9.
>
> But I think for now, it's not so bad if you run things like init,
> clone using plain hg, then connect to the result repo with the
> cmdserver.

I guess so.

> You're right that the protocol doesn't define how fields look on the
> hello msg. I think we should define it now.
>
> It can be a line separated list of
>
> <field name>: <field data>
>
> where <field name> is restricted to [a-z0-9]+ and <field data> is
> field specific.

Sounds good, thanks!

>> You write "raw data" for the 'I' channel, but I guess the data on the
>> 'L' channel is just as raw?
>
> Well yeah. The main difference is when the server uses each one.
>
> Without the 'L' channel, interactive commands will be difficult on the
> client. Because the decision of when the server needs one line moves
> to the client, which is a lot harder for him and depends on the
> context (that the server already has).
>
> Imagine a client that runs "hg record", where the server output goes
> to stdout and input is read from stdin.
>
> <server sends client first diff>
> <server asks client for 4096 bytes at most (to decide if to accept the
> diff or not)>
>
> At this point the client needs to figure out that all the server
> really needs is one line, which will cause it to emit the next diff.
> But without this hindsight the client will try to consume 4096 bytes
> from stdin, which effectively means it needs to give an answer to all
> diffs in one go.

You mean the client asks the (human) user for 4096 bytes that it can
send to the server? I'm imagining a more high-level interface where the
code for record to track very carefully where it is in the overall
process and so it would have a reply_to_hunk method which takes an enum
type with the 8 options that record accepts. So the querying of the user
would be far removed from the library code.

>> The doc says that the line should be "trimmed to length". Both Java
>> and .NET happen to call their str.strip equivalent trim", but you
>> mean that one can send up to length bytes, right?
>
> Yeah, although it's more "should" than "can": the returned data by the
> client must not exceed <length> bytes.
>
> I'll change the "trim" wording on the wiki so people are not confused
> like you said.

Thanks. I know I'm being pedantic, but I'm trying to make sure that
others wont ask these more or less silly questions :-)

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/


More information about the Mercurial-devel mailing list