On Fr, 2011-01-14 at 04:57 +0000, Sateesh Kavuri wrote: > Hi, > > Some clarifications and the design philosophy of Buteo sync: > * The hcontacts plug-in is not a reference plug-in, but is *the* > plug-in that is used for all Contacts sync for the device.
But third-party sync plugins for Buteo, say "ACME Web Service Sync", are meant to provide their own contacts storage plugin together with their sync plugin, right? Incorporating their specific requirements in the core hcontacts plugin would be both impossible and undesirable for all involved. Now, in MeeGo core we don't have that option, so there's the conflict between peer-specific modifications and general-purpose usage that I had in my email. How do you intend to resolve this conflict? By not adding peer-specific optimizations or with if/else decisions in hcontacts? > * Always use Qt Mobility API of Contacts and not directly the QContacts > API. This ensures that the code is future proof and does not have to be > changed much, even if QContacts changes. This is even the suggestion > from Contacts folks I don't understand this point. The QContacts API *is* the Qt Mobility API of Contacts, isn't it? Where was an API used which isn't meant to be used? > * We already discussed that the new implementation from QContacts and > QVersit parser should not result in data loss, since the data should be > stored transparently in the database, though the MeeGo contacts UI might > not make use of it. So, the idea is Buteo SyncML transparently passes > the vcard (through QContact object after being parsed by QVersitParser) > to QContacts and this inturn stores the object to the store "The new implementation" - sorry, but I lost track of what is already implemented, in progress, or just a design idea. Can you be more specific? Right now, there definitely is data loss, and we need a solution for that. We can file bugs if you prefer to discuss it on a case-by-case basis and you don't see the problems in your own testing with Google Contacts. > * It is not a good idea to create many plug-ins just to support > different target services, since this will just bloat the whole sync > components and will result in un-maintainable code in the future. I agree. I just mentioned it for the sake of completeness. > Out of the attached 4 patches, patches 3 and 4 are something to be > considered, but 1,2 cannot be taken into use because of the reasons I > provided above Then we need a different solution for the problems that they are solving. About the XML profile patches, when can this be integrated? The bug in the profile currently blocks all testing with Google Contacts in MeeGo. -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Open Source Technology Center Pützstr. 5 Phone: +49-228-2493652 53129 Bonn Germany _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
