<div dir="ltr">On Fri, Sep 7, 2012 at 11:12 AM, Johan Samyn <<a href="mailto:johan.samyn@gmail.com">johan.samyn@gmail.com</a>> wrote:<br>><br>> Hi,<br>><br>> On the wikipage for the Hg CommandServer I read that the results of<br>
> "runcommand" are sent through the "o"utput channel, and then the final<br>> return code through the "r"esult channel. But the result of<br>> "getencoding" is sent through the "r"esult channel immediately. Is there<br>
> any special reasoning behind that decision, cause I find it<br>> inconsequent, and kind of breaks the protocol imho.<div><br></div><div>There wasn't special reasoning other than it made some</div><div>sense to write the return value of a command to the result</div>
<div>channel.</div><div><br></div><div>I don't see how it breaks the protocol though, why do you think</div><div>it does?</div><div><br></div><div>><br>> As I have started working on a client lib, I had to take special<br>
> measurements for this difference, because for runcommand the "r" channel<br>> only contains "channel + returncode", but for getencoding it contains<br>> "channel + length + data".  So what is sent over the "r" channel after<br>
> getencoding looks exactly like what is returned on the "o" channel after<br>> runcommand. So why not send it over the "o" channel then?</div><div><br></div><div>All output by the server has the same header of (channel-id, length)</div>
<div>followed by the data, so the only difference between runcommand</div><div>and getencoding are the contents of data which according to the</div><div>protocol are command specific.</div><div><br></div><div><div>I guess it could have been written to the 'o' channel but currently</div>
</div><div>the 'o' channel is almost exclusively used for stuff Mercurial normally</div><div>writes to stdout so I guess having this distinction is nice.</div><div><br></div><div>><br>> And I'm pretty sure the small example program at the end of the<br>
> CommandServer wikipage doesn't cope with this neither.</div><div><br></div><div>It only uses runcommand, why would it need to?</div><div><br>><br>> Has none of the other lib implementors asked a question about this ? Is<br>
> there any chance this can be 'fixed' yet ? Or am I missing something<br>> completely ?</div><div><br></div><div>Pretty much no chance of this changing.</div><div><br>You can show some code (or look at the various implementations) for</div>
<div>us to understand why this bothers you.</div></div>