On Mon, 27 Jul 2009, Peter Rosin wrote:
My take on this is that you (Cendio?) wants to say "all strings
MUST/SHOULD be UTF-8 unless otherwise specified". I don't get
why you feel that there is need for such strong wording?
Because unspecified encodings are a major problem (as this discussion
indicates).
If we say MUST or even SHOULD, anyone encountering something
else will get the feeling that fingerpointing is prefectly
valid. It is not, and we can't change that fact since we do not
own the spec.
Yes, we own our spec.
We can only recommend the sanest exit from this
mess and hope for the best.
Agree.
The only thing we are going to accomplish by papering over the mess is
that we end up with an incompatible (and therefore useless) spec.
Disagree.
I say: State that the encoding *is* unspecified but (probably)
ASCII-compatible, *recommend* everybody to use UTF-8 (and ASCII
when sending data with extreme portability requirements) and be
done with it. Again, why do you need to include MUST/SHOULD?
Because otherwise the problem will not go away.
Also, you dismissed the VeNCrypt extension rather lightly on
the grounds that it is not in the spec. I think that's rather
narrow minded; we should make every effort to ease adding
documentation for old extensions. By introducing incompatible
changes such as this we make it more difficult for ourselves
later on.
I disagree, I think we can add the VeNCrypt extension later on without too
much trouble.
If I have a server and I want it to say "Skåne" if I know UTF-8
is supported by the client and "Skane" otherwise (since perhaps
I really really detest the looks of "Sk&%ne", but still
strongly dislike "Skane"), I must have a way to automatically
determine if UTF-8 is supported.
Just make sure you are using updated clients. Current clients cannot
corretly display a non-ASCII way in any sane way in any case.
Also, later on we want some way to change ServerCutText and
ClientCutText to take UTF-8 strings. It would be insane to have
some different mechanism for that job, no? So, we still need
some sort of UTF-8 extension...
As we have discussed earlier, the current clipboard mechanism is very bad
anyway, so we can introduce UTF-8 for the clipboard when designing the new
one. We might need some "extension detection" for this, but it doesn't
make sense to use a "UTF-8 extension mechanism" to determine if the new or
old clipboard system should be used. We need something else for this, but
that's a later problem.
I'm starting to believe that we won't reach full consensus in a near
future. Perhaps it's time to vote?
Best regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------
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
