cmdserver protocol questions

[Idan Kamara]

On Fri, Jul 1, 2011 at 6:20 PM, Martin Geisler <mg at aragost.com> wrote:
> 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.

I'm not saying it's not possible, and I'd imagine a client library doing
something similar to what you described.
But with the line approach, a naive client gets it for free (like the
example client on the wiki).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110702/308d2f60/attachment.htm>