Ämne:RE: SV: [dcdev] Anyone still alive?
Från:Gustaf Räntilä <[email protected]>
Till:"'Direct Connect developers'" <[email protected]>
Hey there, I think there needs to be a standard. Either case=20 sensitivity or not, and I prefer not. When are case=20 insensitivity matches taking place? Only on login to check=20 user name? In that case, It's not like every command needs=20 these checks, and I'm not sure why this would be heavy for a=20 hub. I kind'a don't like the idea of forcing nick names into=20 a specific case. We already have that when logging into unix=20 machines and in many other computer domains for usernames...=20 Personally I don't like it, but it's not the end of the world.Now hubs have to ensure the nick's unique case-sensitive (this really = means that clients shouldn't be confused/crash (dc++ comes to mind =3D) = by nicks differing only in case). If the hub developer feels like it, = (s)he can still enforce unique case-insensitive nicks (for improved = quality-of-service to the users...).
Well, this is because there is no Standard that defines case sensitivity usage for the protocol. A clear majority of the hubs use Y(n)Hub which has for a long time been case insensitive. Two users with the same nick (except for their cases) are not allowed, and a user can change nick case and re- login, if I got Yoshi's statement correctly.
As to speed issues with tolowercase, as long as we only use the first 16 = bits of the unicode chars (which for example windows dows), it's just as = fast as tolowercase'ing a 7-bit ascii string (nearly, disregarding the = doubled memory and lookup table size), so it all boils down to whether = the os supports a good unicode case conversion function, and I believe = most do.=20
Yeah, and as I said, case insensitivity matching isn't something that is to be done too often anyway, so for it being to complex for the implementations is a weak argument I think.
That said, I'll go for case sensitive anyway, insensitivity always = brings more work, and the point is to keep the hub rather simple (in a = perfect world, I'd remove the nick constraint, but I realise that people = might not like looking at cid's to tell who's who...)
And I clearly disagree and believes "user experience" (oh, I hate that expression) should be prioritized higher than a Slightly more complex string routine for nick identification. (Why do I see a lot of "=" and "=20"'s in this mail?) Opera-- DC Developers mailinglist http://3jane.ashpool.org/cgi-bin/mailman/listinfo/dcdev