CommandServer design question
idankk86 at gmail.com
Fri Sep 7 05:22:17 CDT 2012
On Fri, Sep 7, 2012 at 11:12 AM, Johan Samyn <johan.samyn at gmail.com> wrote:
> 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
I don't see how it breaks the protocol though, why do you think
> 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...
More information about the Mercurial-devel