On Fri, Jan 14, 2011 at 10:00 AM, Patrick Ohly <[email protected]>wrote:
> 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. > Yes, they can. But whatever is delivered with MeeGo platform by default (of which Google Contacts sync is), should use the same contacts storage plug-in. > > 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? > For this reason, whatever the extra fields there are would be supported by making use of generic vcard field support from QVersit parser and the generic field storage mechanism from QContact. > > > * 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? > So, whatever fields there are from Google contacts that the MeeGo UI does not support should still be stored to tracker and I believe the Contacts engine has made the necessary changes for it. So we (you can provide a patch if you have one) could check the new implementation from QContacts and see if it works (http://bugs.meego.com/show_bug.cgi?id=4897#c14) > > 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. > We will take this up. The google contacts sync without the credentials in the other XML seems to be more of a bug. -- Sateesh
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
