opensync-devel

[Opensync-devel] evolution capabilities

[Mark E. <ma...@mp...>]

Hiya

I've attached a patch, would appreciate anybody present glancing over it
as a quick sanity check, as I'm still not completely sure about
capabilities.

We've discussed evo sync and capabilities before. Since then I
encountered a more specific problem. Create a sync group between file
and evo, create a new calendar object (event, task, or journal) on one
side or the other, and sync, it works ok. Create a new object on both
sides, file sync gets the object from evolution, but evolution gets a
new empty object, wierd !

So eventually I disabled all the capability code in evo sync, and it
"fixed" the problem. Evo sync currently builds capabilities for
contacts, but not any other objtype, so apparently opensync reads this
as the other objtypes having no capabilities at all.

So, attached patch adds capabilities for calendar objtypes. This info
can't be gained from evolution like contact capabilities can, so I've
put it together the best I can through experimentation. I don't want it
committed yet, but would appreciate someone else eyeballing it briefly
before I get it tested by the guy that brought this to my attention
using synce and evo.

As an addendum, this would suggest to me that capabilities in opensync
are a bit off, since they obviously aren't applied when syncing the
single object one way in the example given above. I'm a long way off
working out why, or even where, that is going wrong, so if anyone else
wants to look ....

Ta
Mark

Re: [Opensync-devel] evolution capabilities

[Chris F. <cd...@fo...>]

On Thu, Sep 26, 2013 at 02:25:01PM +0100, Mark Ellis wrote:
> So eventually I disabled all the capability code in evo sync, and it
> "fixed" the problem. Evo sync currently builds capabilities for
> contacts, but not any other objtype, so apparently opensync reads this
> as the other objtypes having no capabilities at all.

I don't understand this behaviour yet.  This needs some investigation
I thinkg.


> So, attached patch adds capabilities for calendar objtypes. This info
> can't be gained from evolution like contact capabilities can, so I've
> put it together the best I can through experimentation. I don't want it
> committed yet, but would appreciate someone else eyeballing it briefly
> before I get it tested by the guy that brought this to my attention
> using synce and evo.

Sorry to mention this so late, after you've done the work, but I think
there is a file format for capabilities already, in XML.  If we can't
auto-detect them in code, we should be able to just write a capabilities
file and have opensync load it.

See the misc/capabilities/ directory in opensync.  I believe the kdepim
plugin uses this as well.

- Chris

Re: [Opensync-devel] evolution capabilities

[Mark E. <ma...@mp...>]

On Fri, 2013-10-11 at 03:14 +0200, Chris Frey wrote:
> On Thu, Sep 26, 2013 at 02:25:01PM +0100, Mark Ellis wrote:
> > So eventually I disabled all the capability code in evo sync, and it
> > "fixed" the problem. Evo sync currently builds capabilities for
> > contacts, but not any other objtype, so apparently opensync reads this
> > as the other objtypes having no capabilities at all.
> 
> I don't understand this behaviour yet.  This needs some investigation
> I thinkg.
> 
> 

I know exactly where you're coming from, this was a a most confusing
experience.

> > So, attached patch adds capabilities for calendar objtypes. This info
> > can't be gained from evolution like contact capabilities can, so I've
> > put it together the best I can through experimentation. I don't want it
> > committed yet, but would appreciate someone else eyeballing it briefly
> > before I get it tested by the guy that brought this to my attention
> > using synce and evo.
> 
> Sorry to mention this so late, after you've done the work, but I think
> there is a file format for capabilities already, in XML.  If we can't
> auto-detect them in code, we should be able to just write a capabilities
> file and have opensync load it.
> 
> See the misc/capabilities/ directory in opensync.  I believe the kdepim
> plugin uses this as well.
> 

You're absolutely right, and I thought that would be a great idea, but
then I found out you cant mix the two types, ie static for the calendar
objtypes and dynamic for contacts.

When it didn't work I traced it through the code, it's in
opensync_client_proxy.c, _osync_client_proxy_read_discover_message(). If
we find some static caps, we use those, otherwise we use the caps from
discover. So either we use static caps for all objtypes in evo sync, or
we get the contact caps from evo and build the calendar caps inside the
plugin.

Mark

Re: [Opensync-devel] evolution capabilities

[Graham C. <g+o...@co...>]

On 11/10/13 10:56, Mark Ellis wrote:
> I know exactly where you're coming from, this was a a most confusing
> experience.

My feelings about Capabilities in general.  I never got capabilities to
work properly to my satisfaction in gpesync -- and that was with full
control of both the plug-in and the device (as well as commit access to
the engine if I thought I could improve that part)!

To be fair, the capability problem is one of the hardest parts of the
general sync problem.  In my personal view, opensync has got closest to
solving it but it still has problems.  That is one of the main reasons I
have, recently, turned my attention to SyncEvolution, which doesn't even
try to solve this problem but seems to be good enough in practice.

Graham

Re: [Opensync-devel] evolution capabilities

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

On Fri, 2013-10-11 at 11:29 +0100, Graham Cobb wrote:
> To be fair, the capability problem is one of the hardest parts of the
> general sync problem.  In my personal view, opensync has got closest to
> solving it but it still has problems.  That is one of the main reasons I
> have, recently, turned my attention to SyncEvolution, which doesn't even
> try to solve this problem but seems to be good enough in practice.

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

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.

-- 
Bye, Patrick Ohly
--  
Pat...@gm...
http://www.estamos.de/

Re: [Opensync-devel] evolution capabilities

[Graham C. <g+o...@co...>]

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?  Or does one have to be a superset of the
other?

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

Graham

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.