Den 2009-08-12 15:13 skrev Peter Åstrand:
> On Wed, 12 Aug 2009, Peter Rosin wrote:
>
>> Huh? If an existing client treats the incoming desktop name as if it
>> is in the ansi code page (I think most Windows clients do effectively
>> that), and our spec says that it MUST treat it as UTF-8, how is that
>> not an incompatibility?
>
> Since the encoding hasn't been defined earlier, they cannot depend on
> that behaviour.
>
> Besides, didn't we agree on that there is no such server that sends
> strings with the "ANSI CODE PAGE"?
No we didn't, we agreed on that for the desktop name. And besides,
*clients* are using all kinds of ASCII compatible encodings, and will
happily display whatever they receive using their selected encoding.
If we say "MUST use UTF-8" in our spec we declare all those clients
incompatible, and I for one don't wish to do that. They were "legal"
yesterday with the RealVNC spec, and I think they should be "legal"
tomorrow with *both* the RealVNC spec and our spec.
>> You once said "just make sure you are using updated clients", so how
>> is it a problem for you if the rest of the world ignores our spec?
>
> I'm not saying it's a problem. "The rest of the world is free" is free
> to follow which protocol spec they want, if any. But realistically, why
> would anybody want to settle for something else than UTF-8, if:
>
> * This is what Xvnc uses today.
> * This is what we are (as suggested) mandating in our spec
> * This is what RealVNC uses in their "next generation" protocol
>
> ? I really don't see that happen.
If it is so natural with UTF-8 and if it really is the only sane choise
(I think it is), it's enough if our spec says (e.g.)
It is strongly recommended that all implementations use
UTF-8 for all strings (except explicitely stated otherwise)
to ensure interoperability. But be prepared that not all
implementation do, so fail gracefully if you receive
something else.
instead of (e.g.)
All implementations MUST use UTF-8 for all strings (except
explicitely stated otherwise). But not all implementations
do, so you SHOULD fail gracefully if you receive something
else.
I just don't see why the wording with MUST/SHOULD is so superior
that it is worth rendering existing implementations incompatible
with our spec.
>> Look, I agree that the only sane thing to implement in the code is
>> to treat every unspecified string as UTF-8. Most vnc implementations
>> don't do that currently (I think), so that work is needed regardless.
>
> All software running on modern, default Linux systems does, since they
> are running in an UTF-8 locale.
You are ignoring all strings in the protocol besides the desktop name.
And why should the server side decide? Clients are also dealing with
the protocol and *lots* of them do not use UTF-8 for the desktop name.
>> So the question is how to word the text encoding section of our spec.
>> If we owned the protocol, MUST/SHOULD would be the way to go, no
>> question about it. But we do not.
>
> Look, you are starting to sound like some of the RealVNC folks,
> repeating the words "official", "standard" and "real" in every sentence.
But they are right. E.g. UltraVNC clients are are a *pain* to handle
if you are implementing a server, because they do not follow the
official spec. UltraVNC servers are easier... So I can understand
that they are upset by "protocol abuse".
> Nobody can "own" a protocol; it's a convention made up to be what the
> participants wants it to be. Currently, "we" are (as far as I know) the
> only project trying to document the details of the VNC protocol, so we
We have forked the RealVNC spec, how can you claim we are alone?
> really have no competition in this area. But we could have; anyone can
> fork the spec as well as they can fork the code. A particular
> implementor can choose which or any spec he wants to follow, hopefully
> based on how "good" he considers the spec to be. So let's concentrate on
> making our spec as good as possible, instead of debating whether it's
> "official" or not.
Yes, so let's not make existing implementations incompatible with our
spec.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
tigervnc-rfbproto mailing list
tigervnc-rfbproto@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
