On Tue, 2016-10-04 at 23:03 +0200, deloptes wrote: > Thank you for the extended explanations in your reply. > > Patrick Ohly wrote: > > [old content removed for visibility] > > > > >> Alternatively can we enforce text/calendar instead of text/x-vcalendar? > >> I tried setting this in the ini file > >> .config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini > >> but the engine refused with error. > > > > Was it a local error or did it occur after contacting the phone? > > Probably the latter. > > > > I think it was a 10500 error.
The log then probably had a better explanation, but I'm sure it was what I described. > >> I am not even sure that this is OK to > >> modify the file and expect to work. > > > > The Synthesis engine is able to exchange data in different formats and > > the configuration options control that aspect. However, the peer it > > talks to must support the same formats, which is not possible in this > > case: in it's DevInf, the N9 only reports "type=text/x-vcalendar, > > version=1.0" for its ./calendar data store. > > > > The expected error then is something about "no common format" (not sure > > what the wording is). > > > > So once again, please confirm. The configured "type=text/x-vcalendar" in > .config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini > does not enforce the phone to respond, rather it is based on the > capability - correct? Correct. Basically SyncEvolution starts a sync by telling the phone what data stores it wants to sync, and then the phone describes what kind of data formats it accepts for those stores. SyncEvolution does the same, and then both sides decide based on the received information in which format they send data. SyncEvolution can try to coerce a peer to send data in a certain format by only listing that format as supported, but that only works if the peer supports that format and checks the information sent by SyncEvolution. I only know of one SyncML implementation that supports this, and that is the Synthesis engine used by SyncEvolution. > > vCalendar is a very limited format and only poorly supports modern > > concepts (meeting series, exceptions, time zones). Shoehorning iCalendar > > 2.0 data into vCalendar 1.0 is problematic. > > > > It looks to me that indeed it only supports "type=text/x-vcalendar", > although I would expect text/calendar by KCalExtended. I think I have > somewhere sources - I'll try to dig a bit. There's a bit of history, too, here: there were discussions to use SyncEvolution as SyncML implementation in MeeGo (which would have given you iCalendar support also for SyncML), but Nokia preferred their in-house implementation (which is limited to vCalendar). That implementation is what you are talking to now. > Anyway, I don't know what interest Intel or Canonical have in this project. Intel was using SyncEvolution for example in Moblin Netbooks and more recently for phone support in Tizen IVI. Canonical is using SyncEvolution for data synchronization in Ubuntu, mostly the phone flavor. > It looks like a very good work so far and I hope whoever works on this > further will maintain this level. Even this parser seem to work well if it > gets the right data, no matter how ugly it looks. > > Last but not least, you are also really nice and helpful. I still feel responsible for SyncEvolution and definitely want to ensure that users who have an interest in it have the possibility to use it. But as in your case, there's also real life and family, so the situation is different now compared to previous years. -- 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 [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
