On Wed, 12 Aug 2009, Adam Tkac wrote:
If I watch this thread correctly there are two points of view:
1. one side would like to fire away all non-UTF-8 strings, which means
the older software will become incompatible (bad)
I don't agree with this wording. I don't think that older versions would
be "incompatible".
2. another side would like to use unclear specification, which means
the problem will be never solved (bad)
In my opinion the best solution will be to create new pseudo encoding
called "UTF-8". If one side doesn't support UTF-8 strings it means
that strings will be in old format (which effectivelly means
unspecified encoding). If both sides declare that they support UTF-8
all strings will be sent in UTF-8. We should also declare that all new
software MUST send strings in ASCII if it doesn't support UTF-8 or in
UTF-8.
This is basically what Peter Rosin has been suggesting, as I understand
it.
I don't like it at all. If you try to create a patch, for both the spec
and our implementation, that implements this, I think it will show that
the amount of work/code/complexity required is very large and is hard to
justify. Then you will also need to convince every other compatible VNC
implementation out there that they should implement this new extension
that we have defined, which isn't even in the /official/ protocol
specification...
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
