Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Fri, 2016-11-18 at 16:35 +, Graham Cobb wrote: > On 18/11/16 15:06, Patrick Ohly wrote: > > SyncEvolution can be used in such a mode - one just needs a central hub > > which supports the full semantic and attributes of everything that one > > wants to sync, and the description of what each peer supports has to be > > accurate. Unfortunately, in practice both conditions aren't completely > > met. > > I don't think either condition is anywhere near being met. Darn, there goes my self-delusion. > What backend would you suggest can be used which "supports the full > semantic and attributes of everything that one wants to sync"? I am not > aware of one, but I have only tried a few. The EDS backend has full iCalendar 2.0 support and fairly complete vCard 3.0. In both cases, additional properties can be (okay, could be) stored as extensions. However, Evolution itself does not know about custom SyncEvolution-specific extensions (should they get added), so while in theory it should leave them alone, in practice that's not guaranteed. The same is true for CalDAV and CardDAV servers: extensions are supposed to be stored and preserved, but not everyone follows that. > The second condition is the most serious. In my experience of my many > devices over the years, the question of support is the hardest. The > combinations of design limitations, bugs and strange interactions > (attribute X can't be set if attribute Y is set) is really hard to > define. Even in the case where I knew the code intimately (the GPE > implementation for Maemo) the description language could not express the > restrictions I knew about (let alone the unknown bugs!). True. The profiles in SyncEvolution try to take care of different representations, but there are always differences that are going to be problematic. > > That happens also in 1:1 syncs and is unrelated to multi-way syncing. > > In my experience it is a much smaller problem in 1:1 cases: typically > things are either supported or not and the worst I see is that syncs may > keep trying to set data which is being ignored -- but no database > changes actually occur on either side if nothing has changed. In the > multi-way case, that turns into the data changing with attributes > toggling on and off or changing values as syncs with different devices > occur, even when no data has actually changed. I haven't looked into it > for some time but I seem to remember that it is partly due to the syncs > not being part of a single sync but appearing to be subsequent events, > making changes that then have to be propagated to other devices. Hmm, when items don't change, no changes should be applied and syncing repeatedly should be stable. > I am not blaming SyncEvolution -- I am just not convinced that multi-way > sync can ever be replaced by a series of two-way syncs. That's something that would be worthwhile investigating in depth. Until then we have to agree to disagree ;-} -- 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 SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On 18/11/16 15:06, Patrick Ohly wrote: > SyncEvolution can be used in such a mode - one just needs a central hub > which supports the full semantic and attributes of everything that one > wants to sync, and the description of what each peer supports has to be > accurate. Unfortunately, in practice both conditions aren't completely > met. I don't think either condition is anywhere near being met. What backend would you suggest can be used which "supports the full semantic and attributes of everything that one wants to sync"? I am not aware of one, but I have only tried a few. The second condition is the most serious. In my experience of my many devices over the years, the question of support is the hardest. The combinations of design limitations, bugs and strange interactions (attribute X can't be set if attribute Y is set) is really hard to define. Even in the case where I knew the code intimately (the GPE implementation for Maemo) the description language could not express the restrictions I knew about (let alone the unknown bugs!). > The file backend is a bit limited in that it does not fully support > iCalendar 2.0 semantic. It can store individual VEVENTs, but it doesn't > know about relationships between items sharing the same UID. I'm not > sure anymore what the implication was in practice - might only be > relevant when dealing with peers which themselves do not support the > semantic. If I remember correctly, this restriction is an issue for recurrence exception handling. But I haven't looked into it recently. > I suspect the reason for the spurious changes was more related to poor > conversion between Outlook data formats and the master storage. As soon > as a peer is expected to store data correctly and then doesn't, that > undesired modification may get propagated back. There is certainly a serious issue with Outlook as some of the object semantics are just different from the implied semantics in the vformats and cannot be reliably converted. But I also see problems with Owncloud & KDE. It particularly affects non-standard attributes, which keep coming and going and never stabilise even when no changes are happening on any device. > That happens also in 1:1 syncs and is unrelated to multi-way syncing. In my experience it is a much smaller problem in 1:1 cases: typically things are either supported or not and the worst I see is that syncs may keep trying to set data which is being ignored -- but no database changes actually occur on either side if nothing has changed. In the multi-way case, that turns into the data changing with attributes toggling on and off or changing values as syncs with different devices occur, even when no data has actually changed. I haven't looked into it for some time but I seem to remember that it is partly due to the syncs not being part of a single sync but appearing to be subsequent events, making changes that then have to be propagated to other devices. I am not blaming SyncEvolution -- I am just not convinced that multi-way sync can ever be replaced by a series of two-way syncs. Maybe when I retire I will have time to do more work on this. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Fri, 2016-11-18 at 14:08 +, Graham Cobb wrote: > On 18/11/16 13:03, Patrick Ohly wrote: > > With multi-way you mean a sync topology that has cycles? Yes, that's > > indeed not possible with SyncEvolution. I also don't see a way to do it > > as long as one is stuck with existing data formats. > > Actually, I meant even without cycles. It seems to me from my own > experiments that it is impossible (in the real world) to keep N > 2 > devices in sync just using pairwise syncs (assuming changes on any > device, but disallowing conflicting changes). The main problem is > different sets of supported attributes. > > That was the problem OpenSync tried to solve (with its centralised > database and lists of supported attributes) but SyncEvolution ignores (a > very reasonable but large simplification). SyncEvolution can be used in such a mode - one just needs a central hub which supports the full semantic and attributes of everything that one wants to sync, and the description of what each peer supports has to be accurate. Unfortunately, in practice both conditions aren't completely met. SyncEvolution has to be the SyncML server, too, which it is, under the hood, when using SyncEvolution with ActiveSync or CalDAV/CardDAV. As soon as one allows to let a remote SyncML server do conflict handling, one is pretty much at the mercy of that server. > I have tried to simulate this by using a files backend as a common point > to synchronise everything with, but I still see a lot of spurious > changes and corruptions being propagated around. The file backend is a bit limited in that it does not fully support iCalendar 2.0 semantic. It can store individual VEVENTs, but it doesn't know about relationships between items sharing the same UID. I'm not sure anymore what the implication was in practice - might only be relevant when dealing with peers which themselves do not support the semantic. > That means that, for the time being, I am forced to treat Outlook as my > master and only do one-way syncs from there to my other devices. I suspect the reason for the spurious changes was more related to poor conversion between Outlook data formats and the master storage. As soon as a peer is expected to store data correctly and then doesn't, that undesired modification may get propagated back. That happens also in 1:1 syncs and is unrelated to multi-way syncing. -- 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 SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On 18/11/16 13:03, Patrick Ohly wrote: > With multi-way you mean a sync topology that has cycles? Yes, that's > indeed not possible with SyncEvolution. I also don't see a way to do it > as long as one is stuck with existing data formats. Actually, I meant even without cycles. It seems to me from my own experiments that it is impossible (in the real world) to keep N > 2 devices in sync just using pairwise syncs (assuming changes on any device, but disallowing conflicting changes). The main problem is different sets of supported attributes. That was the problem OpenSync tried to solve (with its centralised database and lists of supported attributes) but SyncEvolution ignores (a very reasonable but large simplification). I have tried to simulate this by using a files backend as a common point to synchronise everything with, but I still see a lot of spurious changes and corruptions being propagated around. That means that, for the time being, I am forced to treat Outlook as my master and only do one-way syncs from there to my other devices. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Running test cases without network access
On Fri, 2016-11-18 at 14:16 +0100, Tino Mettler wrote: > Btw., I just uploaded 1.5.2 to Debian Sid. Thanks! :-) -- 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 SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Running test cases without network access
On Fri, Nov 18, 2016 at 13:21:04 +0100, Patrick Ohly wrote: [...] > "client-test SyncSource::eds_contact > SyncSource::eds_event ...eds_memo...eds_task" > runs the tests for the corresponding PIM backends. For EDS, those are > local. This depends on --enable-integration-tests, which is fine for > production binaries. > > For production binaries, there's also the test-dbus.py testing. But some > of those tests depend on a peer and there's no easy way of skipping just > those tests. This could be added, though. Hi, thanks a lot. That sounds less complicated than I expected. Btw., I just uploaded 1.5.2 to Debian Sid. Regards, Tino ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Wed, 2016-11-16 at 09:48 +, Graham Cobb wrote:
> On 16/11/16 08:43, Tino Mettler wrote:
> > On Wed, Nov 16, 2016 at 08:16:29 +0100, Patrick Ohly wrote:
> >
> > [...]
> >
> >> while Buteo was a "cleanly designed" framework which avoided doing
> >> any of the hard work and delegated that to "plugins". In other
> >> words, it didn't actually solve the problems.
> >
> > OpenSync reloaded? :-)
>
> Oooh, a bit of a low blow :-)
Emotions running high ;-)
> I certainly learnt a lot from spending quite a lot of effort trying to
> make OpenSync work! The main one (and the main reason I am here) is
> that sync is **really** hard to do in the general case.
Amen to that.
I don't have a problem with trying out different ways of doing syncing.
Sometimes people have to try first before they realize how hard it is.
I'm just a bit sad and disappointed when those attempts then tie up
resources for years without actually leading to something that helps
users.
Then there are the projects with great claims ("Synchronize your your
PIM data to your mobile phone, iPod, Nokia Internet tablet, or between
computers" - search for it, it's a verbatim copy) although that's at
best a goal for the future. At least users find out about that as soon
as they dig deeper.
Worse is to sync data and then break it along the way, because then
users stop using sync software.
> Syncevolution does a great job on two-way sync but it would be really
> good to solve the multi-way problem one day :-)
With multi-way you mean a sync topology that has cycles? Yes, that's
indeed not possible with SyncEvolution. I also don't see a way to do it
as long as one is stuck with existing data formats.
--
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
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] Running test cases without network access
Hi Patrick, for the Debian build, I'd like to enable the part of the test suite that does not require network access. Is this possible in a trivial way? If yes, how? Regards, Tino ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
