Version: unknown (using KDE 3.1.9) Compiler: gcc version 3.3.1 OS: Linux (i686) release 2.4.22 Currently, the IRC server name is used as the account identifier. This is inappropriate for IRC as there can be many servers associated with one network, and what servers are available on each network fluctuate greatly. This identifier also prevents the addition of multiple-server functionality, where Kopete could cycle through a list of IRC servers in case one was down or unavailable. For example, I wanted to change one of my IRC accounts from irc.kde.org to calvino.freenode.net. I found the textbox noneditable (though non-greyed out???), so I went and edited the config file. I found that that identifier was also used in the contactlist.xml file, so I had to change it for each entry in there as well - but with that done the manual changeover worked fine. It would be more appropriate to name the connection "Freenode", with an associated server of calvino.freenode.net. This would allow future expansion for multiple servers to be associated with one network, and would allow the server to be easily changed on the fly now. An example of why this would be valuable? Let's say I'm using Kopete on a laptop, and switch between two or more ISPs based on location. I can connect to one efnet server from ISP1 (let's call it irc.isp1.net), but not when connected via any other ISP. The same holds true for irc.isp2.net on the ISP2 connection. Maybe I even have a third ISP that doesn't have an efnet server, so I have to use a subobtimal server such as irc.prison.net in this case. So if I could have one account for Efnet with servers of irc.isp1.net,irc.isp2.net,irc.prison.net; Kopete could try them each until it reached the first successful. However the Network name should be editable in the GUI, because occaisionally they change (for example, LinPeople --> OpenProjects --> FreeNode). From my standpoint as a database designer, this name should only be stored in exactly one place, in the kopeterc file, where a unique identifier (i.e. accountId: 0) would be mapped to the account, and only that identifier (which wouldn't ever need to change) would be used in the contactlist.xml file (and any other places). This would allow the network name to be changed by editing it in a single place (or using the GUI).
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