Re: [Opensync-devel] evolution capabilities

[Patrick O. <pat...@gm...>]

On Mon, 2013-10-14 at 18:54 +0100, Graham Cobb wrote:
> On 14/10/13 17:11, Patrick Ohly wrote:
> > Actually, SyncEvolution uses a library, libsynthesis, which does have
> > support for something like capabilities. The library supports tracking
> > of which properties are supported by each side and ensures that
> > properties supported only by one side do not get lost. Look for "field
> > list" in this introduction:
> > https://syncevolution.org/development/pim-data-synchronization-why-it-so-hard
> 
> Interesting.  I think I had missed that (maybe because I hadn't paid any
> attention to SyncEvolution until I looked at it as part of Meego, and
> Meego was a bit of a special case).
> 
> Does it handle syncing between two devices where each stores attributes
> the other doesn't know about?

For this to work, both sides need to run SyncEvolution or some other
SyncML implementation which is able to preserve properties not supported
by its peer. In such a scenario, both sides can preserve properties that
the peer doesn't support and it is not necessary to have a superset on
either side.

> Or does one have to be a superset of the
> other?

That helps if the less capable side also has a less capable SyncML
implementation, because then the more capable side will be able to avoid
data loss without relying on the peer to do that itself.

The more capable side needs to know about different ways of encoding
information that is not standardized by vCard, but
SyncEvolution/libsynthesis has rules for that (for example,
X-EVOLUTION-SPOUSE in EDS vs. X-KADDRESSBOOK-X-SpousesName in KDE vs.
X-SPOUSE elsewhere).

> > That and some per-device scripts work fairly well for SyncML devices.
> > For other kinds of syncing (say, EDS <-> Google via CardDAV) there are
> > currently no capabilities on the CardDAV side and properties get lost;
> > I'm working on it, now that Google CardDAV is the main method of syncing
> > with Google contacts. It wasn't necessary for CalDAV servers.
> 
> I suppose we will need to think about it for Exchange as well.

True. As you said earlier, it comes down to whether it matters in
practice. I consider the contact data mapping in activesyncd complete
enough to work okay without a detailed capability description.

With Google CardDAV, some properties are nor supported by Google (URL,
for example) and some others are not supported by SyncEvolution/EDS
(custom labels). See the SyncEvolution 1.3.99.5 release announcement for
some more information and the test/testcases commit log on the master
branch for details.

But this is getting off-topic here. Let's follow up on
syn...@sy....

-- 
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.