[Kde-pim] Future of libkpimidenties.

Ingo Klöcker kloecker at kde.org
Mon Jun 25 22:53:19 BST 2007


On Monday 25 June 2007 23:13, Tom Albers wrote:
> Op ma 25 jun 2007 21:27 schreef u:
> > No. libkpimidenties will no longer depend on libkleo if the
> > Kleo::CryptoMessageFormat member variable (and the other variables
> > I mentioned) is replaced by a simple QVariantMap.
>
> Ingo,
>
> Thanks for lookin into this and coming up with a good solution for
> pimidentites. It is appreciated. As it seems we have agreement on the
> future of this lib, I will copy over this library tomorrow (after
> tagging) and start working on this.
>
> Your explanation looks clear, except the bit about storing the keys
> as a static const somewhere. I'm wondering if a simple enum would be
> a solution, what are the disadvantages compared to your suggestion?

With QString/const char * keys (and proper namespacing rules, e.g. 
similar to the dbus names) everybody can store her own properties in 
KPIM::Identity without risking a clash with the keys of someone else. 
With integers such a namespacing is impossible.

Among our "inner circle" we can/should define a few keys in a shared 
file so that we can easily share those properties, but we cannot know 
what other people will put into KPIM::Identity.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070625/113715e7/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/


More information about the kde-pim mailing list