Summary: | Server name should not be unique identifier for IRC accounts | ||
---|---|---|---|
Product: | [Applications] kopete | Reporter: | Casey Allen Shobe <cshobe> |
Component: | IRC Plugin | Assignee: | Kopete Developers <kopete-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | k9ao |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Casey Allen Shobe
2003-09-21 10:12:14 UTC
Subject: Re: [Kopete-devel] New: Server name should not be unique identifier for IRC accounts While I agree that using the server as account ID is suboptimal and the network name should be used instead I'd like to point out that I really don't like the fact that accountId() can change during the course of a Kopete session, as it complicates the API a lot. I'd much rather prefer to see it being const, and in the rare case where networks change names you simply create a new account. Would that be acceptable? As for your mentioning of how relational databases work: it's not hard to do the same in Kopete, but all the lookups would get rather unreadable soon. What *might* be a solution with the current API is to move away from using the account id STRING everywhere to the POINTER instead. In the past we started using strings almost everywhere because we had tons of invalid pointers, but these days I think the API is more stable and we can move away from it again. Not for KDE 3.2 though :) > I'd much rather prefer to see it being const, and in the rare case where
> networks change names you simply create a new account. Would that be
> acceptable?
Yes, well it's acceptable for me anyways, because the name of the network name
doesn't really matter at all except for aesthetics. I just mentioned the
database perspective in an idealistic sense, but I do agree that it would
affect readability of the configuration, so it was a bit of a stretch (though
would you mind sending me a brief explanation of what pointers are and how they
work at your convenience?).
As long as all the noneditable fields are greyed out, so the user doesn't get
confused as to why they can select text but not type (I was suspecting a
kdelibs bug at first). I wonder if the style guide mentions noneditable
fields. It should, and they should always be greyed out (at least IMHO).
It is not acceptable to use the network name instead of the server name. Many people have preferences for servers. For example, I chat alot on EFNet, but *no way in hell* would I trust a client to choose an EFNet server for me. I know the 2 or 3 that are useable for me, and I don't feel like waiting for 15 mins while my client cycles through all these servers that keep rejecting my client for numerous reasons. Remember people, there are lots of other networks besides freenode. Not all servers ar euniform. Some reject certain countries, some only allow certain countries, some require identd, some don't, some have user limits, some don't. You can't just lump them all into one network and say "Go for it!" to the client. However, this does not mean I don't think a network server list should not be present. I think when someone adds an account there should be a dropdown of networks and servers simmilar to what is in XChat. Now as for the account ID being editable, as everyone knows, I fought to the tooth and bone to allow it to be editable for reasons like this on IRC. But we know that did not pan out. I don't know whata good solution is, but having the account ID based on the network is not one of them. > Many people have preferences for servers. Very true, and this is why most people would only have one server defined in a given network. > I know the 2 or 3 that are useable for me I'm saying that you, as the end user, would have to define these networks and the server lists within. Most of the time they'd only be one server. In special cases, you could add your own chosen fallback servers. DO NOT PREDEFINE THE LIST! I definitely agree with this. After all, we don't predefine the AIM accounts for them ;-). *** Bug 72405 has been marked as a duplicate of this bug. *** Network based accounts now in CVS HEAD |