On Mon, 2012-03-05 at 15:10 +0100, [email protected] wrote:
> On Mon, 05 Mar 2012 15:04:36 +0100
> Patrick Ohly <[email protected]> wrote:
>
> > On Mon, 2012-03-05 at 14:28 +0100, [email protected] wrote:
> > > Hi Patrick, i have also another question:
> > >
> > > in case this other sync option, lets call it "add from server", is
> > > not possible/going to be added, does syncevolution support
> > > groups/categories for other protocols than syncml?
> >
> > Not yet. In that case the logic that you would like to have is easier
> > to implement, because SyncEvolution and not the server decide which
> > items on the server are part of a sync.
> >
> > But wait a second. Do you want the filtering to happen on the server
> > or on the N9?
> >
> > Client-side filtering would be possible also with SyncML.
> >
>
> Well, i dont actually care too much if it's the server that sends only
> some items, or if the clients does the filtering after receiving
> everything.
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.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
