> Indeed, better to have all things cleared up...in any case, the major =
> issue with case is that there is no intuitive way of comparing two utf-8 =
> strings case insensitive - you have to convert them to wide chars. =
> Without lowercase, the hub doesn't have to know anything about utf-8 or =
> encodings - it's just shuffling binary data around based on a byte and =
> the (unescaped) eol marker.

I don't think I get this completely, looking at e.g. SUP you write that the
features should be upper-case only, is this a try to remove all lower-case
letters? If so, then fine, clients could send upper-cased nicks whatever
user input case was, to move the 'case insensitive match' to the clients,
but there's a catch; MSG. Will the chat consist of only upper-cased nicks?
That won't look too good, and it would be rather weird to make a utf-8
protocol, but forcing chat nicks to be upper cased. If I've got this right,
how do clients know the case of other clients?
If nicks are to be case sensitive no matter case, i.e. not to be forced
uppered, but 'arne' simply != 'Arne', then why the fuzz about upper cased
featurenames for instance? Or was that just a sanitary question to make it
look good with a generic case? Then it makes sense. 'Cause case sensitive
strcmp in any encoding (such as utf-8) equals memcmp, right? 

Opera

-- 
DC Developers mailinglist
http://3jane.ashpool.org/cgi-bin/mailman/listinfo/dcdev