On Mon, 05 Mar 2012 15:32:42 +0100 Patrick Ohly <[email protected]> wrote: > > Technically it is different. So let's clarify: > * You want (or rather, have) to have one address book on the N9. > * On Google you have multiple different accounts, with one > default address book in each account. > * A sync between a Google account and the local address book > shall not update or delete any contact that did not come from that > Google account. > > Possible implementation: > * Set the QContactSyncTarget > (http://doc.qt.nokia.com/qtmobility/qcontactsynctarget.html) > on each QContact after receiving it from Google. > * Filter local contacts by QContactSyncTarget. > > There's one caveat: > * What is supposed to happen with a newly created local contact? > It won't be associated with any Google account initially. > Shall it be sent to all of them, one default account, or none? > > > So, in principle doing it at client level would be a perfectly fine > > approach. But it is not there, is it? > > If not, and no one is interested in adding it, can you give me some > > tips on how to do it? > > All of that could be implemented in the QtContact backend. Have a look > at src/backends/qtcontacts and how it lists and stores contacts. > > You'll have to figure out a way to determine the sync target. > Conceptually, the database API is independent of the sync in which the > database is used. > > But there's a precedent: the WebDAV API also needs access to the sync > config in which it is used. You can pick URL and username from there > and construct a "sync target" out of them. > > Here's the relevant code: > > WebDAVSource::WebDAVSource(const SyncSourceParams ¶ms, > const boost::shared_ptr<Neon::Settings> > &settings) : TrackingSyncSource(params), > m_settings(settings) > { > if (!m_settings) { > m_contextSettings.reset(new > ContextSettings(params.m_context)); > > ContextSettings(const boost::shared_ptr<SyncConfig> &context) > ... > vector<string> urls = m_context->getSyncURL(); > ... > if (!urls.empty()) { > m_url = urlWithUsername = urls.front(); > std::string username = m_context->getSyncUsername(); > boost::replace_all(urlWithUsername, "%u", > Neon::URI::escape(username)); } > > We also need a way to turn this filtering on and off, because other > users might want the same data on all their sync peers. The "database" > property might be a place to put that config value. >
Thanks a lot Patrick, i will start looking into this. Just one last thing: here i noticed you assumed we have multiple gmail accounts. In principle it would be fine to have just one, if google sends the group information along with the contact over syncml. In this case the client level filtering could be done at this "tag" level, without having to worry for multiple accounts, duplicates, and so fort. And, as a quick hack, i also dont care about two way sync (to avoid the case of a contact that may be filtered out, then by chance added manually), and a standard refresh-from-server would be allright. Therefore i was rather thinking of adding a sort of command line option, where the "allowed" groups/categories could be listed, and after fetching but before storing each contact is checked against this list (maybe together with another option to specify whether OR or AND should be used on the groups). something like: syncevolution --or --gmail-groups work,friends,home google_contacts what do you think about it? oh, and by the way, as far as you know, is google sending group information over syncml? _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
