> I wanna discus what would be best for Kopete contact list Model-Storage > interface. > With Michael Larouche we agreed we'll be using "friend classes" to not bloat > the public API of MetaContact/Group. > Now with friend classes we have two possibilities. > > First: add friend keyword to MetaContact/Group for every interface. > Like XmlMetaContactStorage,OtherMetaContactStorage ... so we will have access > to d-pointer and protected and private members. > In this case to save/restore MetaContact we'll access these members directly. > > Second: We make generic class MetaContactStorage, that will have functions > for saving/restoring and will have access to d-pointer and protected and > private members. By functions for saving/restoring I mean setPicture/picture, > setID/id etc.. > And than XmlMetaContactStorage will only use functions of MetaContactStorage > to save/restore MetaContact. > In this case we don't need to add friend keyword for every > xxxMetaContactStorage to MetaContact and we only have limited access. > > Roman Jarosz
I think we should use the common 3 layers design here. presentation => data => storage and do something that looks like more to what kconfig and the libpim introduced. We are at the data level in the MetaContact, so we should talk to storage, and make the storage handle the caching of the data, instead of having MetaContact doing the data caching. So the private data of MetaContact should be only be pointer to the MetaContactStorage class. And Storage class handle the cache in what ever form and maintain the cache if needed up to date. This way we can have the storage class telling the metacontact that another program have changed some of the data. (ex some infos were updated by kmail and the lib may inform us that an email/UID has changed, so we can act in consequence). Michel _______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
