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