> Yeah, validity indeed but weak as I said, since the result of=20
> the protocol
> shouldn't have much to do with whether an application can be=20
> finished within
> a day or a week. Simplicity and portability... Well yeah,=20
> that's probably
> important *trying to figure out a sound reason for it*... I'd=20
> say the dependence on an xml-parser (and why not zlib/bzip2=20
> etc) is reason
> enough to focus on usability and not simplicity in a sense=20
> that makes no
> sense, unless you're trying to build a hub for a hand held=20
> device, like a
> palm pilot. Read my humble arrogance correctly, I just don't=20
> fancy this so
> over-emphasized issue of super-simplicity. Win32 doesn't need=20
> iconv for
> this issue, even though iconv - as an example - is widely portable.
> To me, speed issues and Reasonable simplicity are the only=20
> really sound ones.
> And if hubs need to check nick for every mc/pm, and that=20
> massively stresses
> the hubs, and that is reason for case sensitivity, then=20
> fine... But then
> again, last-case-caching shouldn't be too much to ask for,=20
> but I dunno, I
> won't write any hubsoft, I'm just raising the question before=20
> protocol gets
> 'stable' ;)

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.

/J

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