On Sunday 13 August 2006 17:57, Olivier Goffart wrote: > Hi. > > So everybody seems to think we need to store the contactlist using akonadi. > We need to define our need, and see if akonadi does suit our need, or if it > may be extend to suit our need. >
I don't think we need to, but whatever. > So i have categorized some kind of information > > For each contact, we need: > > A) MetaContact Level > > A.1) General PIM Data that are used in the contactlist > it's MetaContact::displayName and MetaContact::photo > So that's already in KABC, I can sefelly say it's also in akonady : no > problem > > A.2) some Kopete specific information related to the contact list > it's mainly the name source and the name photo. > > B) Kopete::Contact Level > > B.1) The contact id of each subcontact > The most important, I don't think it would be a problem. > > B.2) different properties, for each sub contact > thats the Kopete::Contact::Properties. It include some standard field, like > email, address, ... . But also sometimes protocol specific stuff. > > B.3) protocol specific stuff > see also section E > > C) Plugin stuff > > Each plugin need to add their own custom field to metacontact (that's the > PluginData) (and for contact?) > It's like the the translator language, or if the encryption is turned on or > off. > > > Additionally, we must store > > D) Groups > > D.1) contactlist hierarchy (what metacontact in what group and eventually > subgroups) > D.2) Group display name and icon > > E) cache of the server-side contactlist. > that allow to perform faster connection and better syncing of change > between the server and the local. > should each protocol store in his own file the cache (like it was in > Kopete 0.4) or store that in akonady as well ? > > > > Ok, do you see another thing that we need ? > I will expose our need on the kde-pim mailing list. _______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
