>In many cases, what you want is actually a simple "import" from another device - but sharing the .vcf or .ics via Bluetooth sharing and then manually importing that via Settings->Apps->People->Import vCard is probably the >better option.
I was amazed at the easyness of the import from N9 to the TOH device - it was a breeze! I believe a simple use case is Jolla->Jolla sync; for instance, if I want to switch from Xperia X to XA2; i have to a) export the contacts to vcard b) install a file editor (from openrepos?) to transfer the file in question over bluetooth to the XA2 c) find the file first d) import the file on the xa2. this is quite cumbersome, not to mention error-prone; a well-defined process with a pretty UI will rock anybody's socks off, even if we are always talking how SFOS is a nerd platform, where bells and whistles are not necessary; but if it wants to grow out of this box, having it's own (non-cloud based!) sync mechanism would definitely help. So im a strong supporter for this syncml! Just my 2 cents here :) On Wed, Aug 7, 2019 at 11:45 AM Chris Adams <chris.ad...@jolla.com> wrote: > Hi, > > Thanks for doing that work! > > I suspect that you are correct regarding the client-initiated syncs (in > this use-mode, each Sailfish OS device assumes that it is both a SyncML > server and a SyncML client, insofar as any change to its database might > trigger a sync with another device (i.e. this device acts as a client) and > any change to the other device's database might trigger it to sync with > this device (i.e. this device acts as a server)). > > This was the fundamental reason why the original calendar sync PR wasn't > able to be merged: the semantics of such "round trip, multiple device" > synchronisation cycles weren't well defined, and instead the sync acted > more as an "import" than a true "sync" (potentially resulting in data > duplication). > > (For example: what happens if you sync contacts 5 times between the > devices? If you get 5x the whole addressbook, resulting in 5 constituent > contacts being linked into a single aggregate contact, then that is clearly > suboptimal / should be fixed before we merge.) > > In many cases, what you want is actually a simple "import" from another > device - but sharing the .vcf or .ics via Bluetooth sharing and then > manually importing that via Settings->Apps->People->Import vCard is > probably the better option. > > Best regards, > Chris. > > > ________________________________________ > From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes [ > delop...@gmail.com] > Sent: Wednesday, August 07, 2019 12:34 AM > To: devel@lists.sailfishos.org > Subject: Re: [SailfishDevel] SyncML Plugin Server question > > deloptes wrote: > > > To dig into it is out of scope for this project, but I wanted to have > > honest opinion. I agree with Sateesh, but then not sure why ref is added > > only on sync session, which makes server die each time you disable > > bluetooth. There is not much one could do from the plugin to prevent > this. > > The logic is in buteo-syncfw. It should be applying to all plugins. > > Hi Chris, all reading this, > > the "digging" has become unnecessary as it came to light what was going on > behind the scene. > > I did a move after testing different scenarios on the test device to put > the > software on my "production" daily/business phone yesterday. > > It took a while to settle all differences mostly in the contacts, which > accumulated over the past two years, but finally the work was done. > > After a successful sync, as we already know from the previous post, the > reference is not removed and the server keeps running. > > The next time the schedule runs to check/retrieve/sync the profiles, it > sees > the bluetooth profile and the server running and that the profile is > enabled. Consequently it tries to start the sync from the phone as a > client - here comes BTConnection from clientplugins/syncmlclient in the > game, but of course on the other side no syncml server is running and it > fails - after which the server is stopped. > > What was the purpose of this? Possible use case is Device A get close to > Device B and Device B asks for a sync. > I can hardly test this, because I would need a second buteo device - AFAIK > Syncevolution does not support this or at least I have never used this > feature. > > > > > > > _______________________________________________ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org > _______________________________________________ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
