On Tuesday 12 April 2005 14:57, Jon Keating wrote: > This will find a 'licquser', but which one? It depends on the way it > is hashed when Licq loads the users. The correct method, would be to > get a Protocol string. (MSN, Licq, Yahoo, etc.) and use the > FOR_EACH_PROTO_USER_START() macro to guarantee that we have the user > we want. If the Protocol isn't specified, we can just go with the > FOR_EACH_USER_START() macro and do whatever, since the user didn't > specify.
No problem. The ID used by DCOP is an internal ID of KDE's addressbook. The Licq interface maintains a mapping to Licq users. I didn't (and don't) know much about Licq's internal identifications methods, for the prototype I assumed that ICQUser->IdString() was unique. If it isn't and there is no ther unique string identifier across protocol plugins, I can find a way to store a mapping to a tuple, protocol ID and protocol specific user ID. Another possibility would be to store the KABC ID in the ICQUser instance and in the respective file. The advantage of the current approach (separate file for mapping data) is that the Licq data files stay unpolluted by foreign keys. I will stay on this route unless you think that the advantage of having it all in one place outweights the foreign extension from your point of view as the application developers/maintainers. Cheers, Kevin
pgpK1ZvHBZPY8.pgp
Description: PGP signature
