Den 2009-08-12 13:49 skrev Peter Åstrand: > 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".
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? >> 2. another side would like to use unclear specification, which means >> the problem will be never solved (bad) I don't agree with this wording. I don't think if a specification uses MUST/SHOULD or not is a determining factor of whether the spec is clear or not. So, the assumed implication that the problem will "never" be solved also falls. Therefore, I don't think 2 is a bad option. >> 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. Not entirely, I have tried to say that some kind of UTF-8 agreement (possibly in a pseudo encoding, but that's not enough for the early protocol elements) is optional and can be added later. I'm in favor of wording the fact that UTF-8 is preferred in a clear way but w/o using the magic words MUST/SHOULD. > 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... 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? Yeah, I know, cheep shot, but I couldn't resist. In your world adoption will somehow go faster if we use MUST/SHOULD, but I don't see why those magic words will make adoption magically faster. And I don't really see how the above is different from trying to convince every other compatible VNC implementation out there that they should implement UTF-8, which isn't even in the /official/ protocol 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. If a vnc implementation has done that work, it should be a piece of cake to just breeze past whatever UTF-8 enabling protocol construct we design. 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. ------------------------------------------------------------------------------ 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
