CommandServer design question

[Idan Kamara]

On Fri, Sep 7, 2012 at 11:12 AM, Johan Samyn <johan.samyn at gmail.com> wrote:
>
> Hi,
>
> On the wikipage for the Hg CommandServer I read that the results of
> "runcommand" are sent through the "o"utput channel, and then the final
> return code through the "r"esult channel. But the result of
> "getencoding" is sent through the "r"esult channel immediately. Is there
> any special reasoning behind that decision, cause I find it
> inconsequent, and kind of breaks the protocol imho.

There wasn't special reasoning other than it made some
sense to write the return value of a command to the result
channel.

I don't see how it breaks the protocol though, why do you think
it does?

>
> As I have started working on a client lib, I had to take special
> measurements for this difference, because for runcommand the "r" channel
> only contains "channel + returncode", but for getencoding it contains
> "channel + length + data".  So what is sent over the "r" channel after
> getencoding looks exactly like what is returned on the "o" channel after
> runcommand. So why not send it over the "o" channel then?

All output by the server has the same header of (channel-id, length)
followed by the data, so the only difference between runcommand
and getencoding are the contents of data which according to the
protocol are command specific.

I guess it could have been written to the 'o' channel but currently
the 'o' channel is almost exclusively used for stuff Mercurial normally
writes to stdout so I guess having this distinction is nice.

>
> And I'm pretty sure the small example program at the end of the
> CommandServer wikipage doesn't cope with this neither.

It only uses runcommand, why would it need to?

>
> Has none of the other lib implementors asked a question about this ? Is
> there any chance this can be 'fixed' yet ? Or am I missing something
> completely ?

Pretty much no chance of this changing.

You can show some code (or look at the various implementations) for
us to understand why this bothers you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120907/b91c3571/attachment.html>