RFC: Command server protocol

[Martin Geisler]

Matt Mackall <mpm at selenic.com> writes:

> On Wed, 2011-06-15 at 14:01 +0200, Martin Geisler wrote:
>> Idan Kamara <idankk86 at gmail.com> writes:
>> 
>> > that is 1234 bytes sent on channel 'o', with the data following.
>> 
>> Could we please use full words for the channels? I think it makes it
>> much easier to remember what's going on if we talk about the 'result'
>> channel instead of the 'r' channel (and there might be new channels
>> in the feature that naturally would start with 'r').
>
> Are you talking about in the documentation or in the protocol stream?

It was for the protocol stream itself. If you think it creates
deadlocks, then we should of course not do it. It's not very important
anyway since the rest of the protocol is kind of low-level.

>> > Encoding
>> > -------------
>> > Strings are encoded in the local encoding.
>> 
>> Uhh, that seems like a bad idea since there can be many things that
>> cannot be encoded in that encoding.
>
> It seems like a great idea. But you know that I think that, because
> you were around for the discussion where I vetoed doing it differently
> on IRC _before_ posting this. One wonders what you're trying to
> accomplish here.

You have mixed up the timezones somehow. I brought the encoding issue up
on IRC at around 6pm local time:

  15-06-2011 18:09:04 > mg: sure -- I don't care as long as we remember
  to send things in UTF-8... I feel that is actually important :)

and I posted this mail four hours before, at around 2pm:

  Date: Wed, 15 Jun 2011 14:01:54 +0200

Please believe me when I tell you that I don't try to "accomplish"
anything strange with my mails -- I don't have any malicious intentions
when I contribute to Mercurial.

>> Since we are defining a new protocol, I think we should take the
>> chance to specify that all strings must be UTF-8 encoded. On the
>> server-side, you will call tolocal on the incoming strings to cache
>> the UTF-8 encoding.
>
> A client is free to set the preferred encoding to UTF-8. It will NOT
> be the default, because sensible clients are encoding
> agnostic/transparent, just like hg itself.

Being able to set the encoding will of course save the day here. That
way the choice of default encoding wont matter so much.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110615/c239d855/attachment.pgp>