Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Mon, Nov 21, 2016 at 19:04:02 +0100, deloptes wrote: > Hi, > yes I would prefer bluetooth as I do not use wireless, or at least avoid > using it. I must have missed something, as I never saw a Bluetooth cable yet. :-) > + I don't have Cal/CardDav server setup. Can SyncEvolution offer Cal/CardDav > functionality as server? It could be interim solution. As already mentioned earlier, syncevolution is not a CalDAV/CardDAV server. I use DAViCal and all my clients (Linux, macOS, iOS) sync with this server. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
Tino Mettler wrote: > On Mon, Nov 21, 2016 at 08:00:33 +0100, deloptes wrote: > > >> devices for me and the question is can be done something for SailFish and >> what, so that I can use SyncEvolution with it via bluetooth. If you know > > Hi, > > is Bluetooth the only option for you? It looks like Sailfish can sync via > CalDAV/CardDAV OOTB. > Hi, yes I would prefer bluetooth as I do not use wireless, or at least avoid using it. + I don't have Cal/CardDav server setup. Can SyncEvolution offer Cal/CardDav functionality as server? It could be interim solution. regards ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Mon, Nov 21, 2016 at 08:00:33 +0100, deloptes wrote: > devices for me and the question is can be done something for SailFish and > what, so that I can use SyncEvolution with it via bluetooth. If you know Hi, is Bluetooth the only option for you? It looks like Sailfish can sync via CalDAV/CardDAV OOTB. Regards, Tino ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
Hi Patrick, Graham, all, Patrick Ohly wrote: > On Tue, 2016-11-15 at 23:04 +0100, deloptes wrote: >> Patrick Ohly wrote: >> > During all that time, SyncEvolution has had a functional SyncML >> > implementation and backends for the PIM storage in MeeGo... >> >> Here is what they said: >> >> Sync via Bluetooth isn't well supported at the moment. We allow importing >> contacts from another device, and adding capability to import calendars >> via Bluetooth is work-in-progress (see >> https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 >> and MER#1222 for that), but true synchronisation via Bluetooth is >> significantly more difficult to achieve with the current stack. > > Reminds me of the discussions we had about comparing Bueto with > SyncEvolution. SyncEvolution always had a strong focus on actually > making syncing work (and yes, that gets ugly sometimes), 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. Too late to say "told you so" now, there's literally > no-one left from those discussions and it wouldn't matter anyway. > >> I guess I have to wait, or get involved. I asked why not use >> syncevolution? but still it would need a backend ... I don't know when >> I'll be able to have a look into the sdk and mer > > I don't know how much current PIM storage in SailFish OS has diverged > from MeeGo; for MeeGo, kcalextended and qtcontacts were the relevant > backends. > the discussion is very interesting. However I am very pragmatic and I would bring you back to the original topic. It should work at least for N=2 devices for me and the question is can be done something for SailFish and what, so that I can use SyncEvolution with it via bluetooth. If you know more than me, can you share or draft a plan what should be done. Thanks ___ 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 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] 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
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Wed, Nov 16, 2016 at 22:57:41 +0100, deloptes wrote: > doesn't syncevolution support a cal/carddav server ... or just a client? Hi, it is just the client side. For the server side, you can try DAViCal if you don't want to run a full blown ownCloud service just for PIM sync. Regards, Tino ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
Graham Cobb wrote: > On 16/11/16 07:16, Patrick Ohly wrote: >> Reminds me of the discussions we had about comparing Bueto with >> SyncEvolution. SyncEvolution always had a strong focus on actually >> making syncing work (and yes, that gets ugly sometimes), 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. Too late to say "told you so" now, there's literally >> no-one left from those discussions and it wouldn't matter anyway. > > Some of us who remember the discussions are still around! But we never > understood the decisions anyway. I will admit that I have given up on > syncing to my Jolla phone for now, even though it is my day-to-day phone. > > If anyone has any ideas on how to actually make it work I would be happy > to join in. And another one http://neo900.org/ you never knew it existed ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
Graham Cobb wrote: > I am sure I used to have a version of SyncEvo on my Jolla, due to the > kindness of someone on the list who built it. I seem to remember it > worked sort of -- was it for calendar or contacts? Anyway it stopped > working (did Jolla change the underlying data store or something? I > can't remember). I haven't bothered recently and have never even looked > for it to try to install on my Jolla C. > I just got this phone last week, so no idea and ATM I am preoccupied, but I am curious to see what the sdk and emulator can do. I read that there was syncevolution 1.3 for jolla, but no confirmation that it works, so now we know that it does not work anymore. >> For the time being I read the only supported way is via Cal/CardDav ... >> and people reported to be using own service ... which s*cks ... > > I do sync with my personal owncloud instance so I have calendar and > contacts in Cal/CardDav form. I have not got around to trying the > Sailfish Cal/CardDav support to see if it works with owncloud but plan > to when I have time. > doesn't syncevolution support a cal/carddav server ... or just a client? regards ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On 16/11/16 20:10, deloptes wrote: > Hi Graham, > they confirmed it is not working on SailFish - who knows when they will > implement it and how it will be implemented ... given the comments > above ... > Perhaps we have to work closer with the Jolla team on it. Or ... get proper > SyncEvolution backend for SailFish. I am sure I used to have a version of SyncEvo on my Jolla, due to the kindness of someone on the list who built it. I seem to remember it worked sort of -- was it for calendar or contacts? Anyway it stopped working (did Jolla change the underlying data store or something? I can't remember). I haven't bothered recently and have never even looked for it to try to install on my Jolla C. > For the time being I read the only supported way is via Cal/CardDav ... and > people reported to be using own service ... which s*cks ... I do sync with my personal owncloud instance so I have calendar and contacts in Cal/CardDav form. I have not got around to trying the Sailfish Cal/CardDav support to see if it works with owncloud but plan to when I have time. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
Graham Cobb wrote: > Oooh, a bit of a low blow :-) > > 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. > > Syncevolution does a great job on two-way sync but it would be really > good to solve the multi-way problem one day :-) But that would require > some significant work by a team who are willing to look at and learn > from all the previous attempts. I sometimes wish Philippe Kahn had not > lost interest in sync. Hi Graham, they confirmed it is not working on SailFish - who knows when they will implement it and how it will be implemented ... given the comments above ... Perhaps we have to work closer with the Jolla team on it. Or ... get proper SyncEvolution backend for SailFish. I'm just wondering what happened to the MeeGo part and why it was not adopted by SailFish ... but anyway. From what I learned with the whole backend exercise for TDE/KDE3, the best is to do the work yourself ... For the time being I read the only supported way is via Cal/CardDav ... and people reported to be using own service ... which s*cks ... I have put on the todo list to have a look into the SDK - no idea when, but it is tempting regards ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
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 :-) 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. Syncevolution does a great job on two-way sync but it would be really good to solve the multi-way problem one day :-) But that would require some significant work by a team who are willing to look at and learn from all the previous attempts. I sometimes wish Philippe Kahn had not lost interest in sync. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Tue, 2016-11-15 at 23:04 +0100, deloptes wrote: > Patrick Ohly wrote: > > During all that time, SyncEvolution has had a functional SyncML > > implementation and backends for the PIM storage in MeeGo... > > Here is what they said: > > Sync via Bluetooth isn't well supported at the moment. We allow importing > contacts from another device, and adding capability to import calendars via > Bluetooth is work-in-progress (see > https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 and > MER#1222 for that), but true synchronisation via Bluetooth is significantly > more difficult to achieve with the current stack. Reminds me of the discussions we had about comparing Bueto with SyncEvolution. SyncEvolution always had a strong focus on actually making syncing work (and yes, that gets ugly sometimes), 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. Too late to say "told you so" now, there's literally no-one left from those discussions and it wouldn't matter anyway. > I guess I have to wait, or get involved. I asked why not use syncevolution? > but still it would need a backend ... I don't know when I'll be able to > have a look into the sdk and mer I don't know how much current PIM storage in SailFish OS has diverged from MeeGo; for MeeGo, kcalextended and qtcontacts were the relevant backends. -- 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
Patrick Ohly wrote: > Huh? Then how did you sync between your N9 and the Sail Fish OS phone? > Why does it advertise SyncML support via Bluetooth? > > I thought Sail Fish OS had continued to use Buteo as its sync solution > because that's what they got from MeeGo, and there was a SyncML > implementation for that (most recent repo probably > https://github.com/kavuri/buteo-syncml). If that's the code, then it has > been "in progress" for several years now. > I had the same impression. > During all that time, SyncEvolution has had a functional SyncML > implementation and backends for the PIM storage in MeeGo... Here is what they said: Sync via Bluetooth isn't well supported at the moment. We allow importing contacts from another device, and adding capability to import calendars via Bluetooth is work-in-progress (see https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 and MER#1222 for that), but true synchronisation via Bluetooth is significantly more difficult to achieve with the current stack. https://together.jolla.com/question/46789/when-can-we-get-pim-functionality-on-par-with-n9/?comment=151330#comment-151330 I guess I have to wait, or get involved. I asked why not use syncevolution? but still it would need a backend ... I don't know when I'll be able to have a look into the sdk and mer regards ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Tue, 2016-11-15 at 21:57 +0100, deloptes wrote: > deloptes wrote: > > > I'll try to find information how this version is supposed to work. Perhaps > > it is missing a service in the background. > > Jolla/Sailfish OS does not have syncml implemented (yet). Work is in > progress, was the answer. Huh? Then how did you sync between your N9 and the Sail Fish OS phone? Why does it advertise SyncML support via Bluetooth? I thought Sail Fish OS had continued to use Buteo as its sync solution because that's what they got from MeeGo, and there was a SyncML implementation for that (most recent repo probably https://github.com/kavuri/buteo-syncml). If that's the code, then it has been "in progress" for several years now. During all that time, SyncEvolution has had a functional SyncML implementation and backends for the PIM storage in MeeGo... -- 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
deloptes wrote: > I'll try to find information how this version is supposed to work. Perhaps > it is missing a service in the background. Jolla/Sailfish OS does not have syncml implemented (yet). Work is in progress, was the answer. thanks and regards ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
Patrick Ohly wrote: >> This is what I did - it loops in ObexTransportAgent::wait(): iteration >> for quite some time, but I guess I have to remove PC suite parameter and >> who knows what I also have to modify. > > That doesn't look good :-( > > Is the phone still supported? Is it possible to see logs from the phone > side or get someone to describe how the phone is supposed to be used for > syncing via SyncML? > Actually it is pretty new. After making sync possible with TDE and N9 I am pretty happy, so now is the time to plan for the future. It is produced by Intex and sold since earlier this year. I thought it will be a nice try since the price is not that high. I still don't know whos in charge on Jolla side ... but I was able to sync the contacts from N9 to Intex Aqua Fish via bluetooth. I don't know how it did it in the background >> >> I tried phone-setup, but the python script dies with an error. >> > >> > Which one? >> > >> > The script hasn't been used much, I suspect. The only remaining phones >> > with SyncML support were Nokia, and those typically all used the same >> > settings. >> >> syncevo-phone-config >> >> syncevo-phone-config --bt-address >> 94:XX:XX:XX:XX:8D --advanced --create-config=aquafish >> Running test with test data inside /tmp/syncevo-phone-config1_7yeN/data >> and test results inside /tmp/syncevo-phone-config1_7yeN/cache >> Starting test for 1188 configurations... >> Start 1/1188 test >> [DEBUG 00:00:00] checking password property 'databasePassword' in >> datastore 'addressbook' of config 'test-phone' with user identity '' >> [ERROR 00:00:00] addressbook: backend addressbook is ambiguous, avoid the >> alias and pick a specific backend instead directly > > That error comes from not knowing whether the Evolution or TDE backend > is supposed to be used by the script. After a quick look at the script > it seems that this cannot be specified. For you, the easiest solution > probably is to disable the Evolution backends when compiling > SyncEvolution. these are the options I compiled with --enable-maintainer-mode \ --enable-shared \ --enable-gui \ --enable-gtk=3 \ --enable-core \ --enable-bluetooth \ --enable-tdepimabc \ --enable-tdepimcal \ --enable-tdepimnotes \ --enable-tdewallet \ --enable-sqlite \ --enable-file \ --enable-dav \ --without-gio-gdbus \ --disable-ssl-certificate-check \ --disable-akonadi \ --disable-ebook \ --disable-ecal \ --disable-goa \ --disable-kcalextended \ --disable-kwallet \ --disable-maemocal \ --disable-oauth2 \ --disable-qtcontacts \ --disable-gsso \ --disable-uoa \ --disable-sign I'll try to find information how this version is supposed to work. Perhaps it is missing a service in the background. regards ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Mon, 2016-11-14 at 20:27 +0100, deloptes wrote: > Patrick Ohly wrote: > > >> How can I get a working template/config for the device > > > > I would start with the Nokia template. > > > > This is what I did - it loops in ObexTransportAgent::wait(): iteration for > quite some time, but I guess I have to remove PC suite parameter and who > knows what I also have to modify. That doesn't look good :-( Is the phone still supported? Is it possible to see logs from the phone side or get someone to describe how the phone is supposed to be used for syncing via SyncML? > >> I tried phone-setup, but the python script dies with an error. > > > > Which one? > > > > The script hasn't been used much, I suspect. The only remaining phones > > with SyncML support were Nokia, and those typically all used the same > > settings. > > syncevo-phone-config > > syncevo-phone-config --bt-address > 94:XX:XX:XX:XX:8D --advanced --create-config=aquafish > Running test with test data inside /tmp/syncevo-phone-config1_7yeN/data and > test results inside /tmp/syncevo-phone-config1_7yeN/cache > Starting test for 1188 configurations... > Start 1/1188 test > [DEBUG 00:00:00] checking password property 'databasePassword' in > datastore 'addressbook' of config 'test-phone' with user identity '' > [ERROR 00:00:00] addressbook: backend addressbook is ambiguous, avoid the > alias and pick a specific backend instead directly That error comes from not knowing whether the Evolution or TDE backend is supposed to be used by the script. After a quick look at the script it seems that this cannot be specified. For you, the easiest solution probably is to disable the Evolution backends when compiling SyncEvolution. -- 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
Patrick Ohly wrote:
>> How can I get a working template/config for the device
>
> I would start with the Nokia template.
>
This is what I did - it loops in ObexTransportAgent::wait(): iteration for
quite some time, but I guess I have to remove PC suite parameter and who
knows what I also have to modify.
>> I tried phone-setup, but the python script dies with an error.
>
> Which one?
>
> The script hasn't been used much, I suspect. The only remaining phones
> with SyncML support were Nokia, and those typically all used the same
> settings.
syncevo-phone-config
syncevo-phone-config --bt-address
94:XX:XX:XX:XX:8D --advanced --create-config=aquafish
Running test with test data inside /tmp/syncevo-phone-config1_7yeN/data and
test results inside /tmp/syncevo-phone-config1_7yeN/cache
Starting test for 1188 configurations...
Start 1/1188 test
[DEBUG 00:00:00] checking password property 'databasePassword' in
datastore 'addressbook' of config 'test-phone' with user identity ''
[ERROR 00:00:00] addressbook: backend addressbook is ambiguous, avoid the
alias and pick a specific backend instead directly
Traceback (most recent call last):
File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 728, in
main()
File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 725, in
main
config.run()
File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 557, in
run
(status, interrupt) = self.testWithCurrentConfiguration ()
File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 438, in
testWithCurrentConfiguration
runCommand ("%s -c --template 'SyncEvolution Client' --sync-property
peerIsClient=1 %s" % (syncevoTest, configName))
File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 271, in
runCommand
raise Exception("%s: failed (return code %d)" % (cmd, result>>8))
Exception: XDG_CACHE_HOME=/tmp/syncevo-phone-config1_7yeN/cache
XDG_CONFIG_HOME=/tmp/syncevo-phone-config1_7yeN/config
syncevolution --daemon=no -c --template 'SyncEvolution
Client' --sync-property peerIsClient=1 test-phone >/dev/null: failed
(return code 1)
I think there was a way to send the SAN or whatever command to get the
config ...
If you have time and help a bit, it would be great advantage for the whole
community
regards
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Sat, 2016-11-12 at 10:17 +0100, deloptes wrote: > Hi, > I am wondering if it is possible to sync Intex Aqua Fish with SailFish OS > via SyncEvolution. > > > sdp browse > > Service Name: SyncML Client > Service RecHandle: 0x10008 > Service Class ID List: > UUID 128: 0002--1000-8000-0002ee02 > Protocol Descriptor List: > "L2CAP" (0x0100) > "RFCOMM" (0x0003) > Channel: 25 > "OBEX" (0x0008) > Profile Descriptor List: > "" (0x0002--1000-8000-0002ee02) > Version: 0x0100 > > Service Name: SyncML Server > Service RecHandle: 0x10009 > Service Class ID List: > UUID 128: 0001--1000-8000-0002ee01 > Protocol Descriptor List: > "L2CAP" (0x0100) > "RFCOMM" (0x0003) > Channel: 26 > "OBEX" (0x0008) > Profile Descriptor List: > "" (0x0001--1000-8000-0002ee01) > Version: 0x0100 > > How can I get a working template/config for the device I would start with the Nokia template. > I tried phone-setup, but the python script dies with an error. Which one? The script hasn't been used much, I suspect. The only remaining phones with SyncML support were Nokia, and those typically all used the same settings. -- 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
