|
From: Daniel G. <go...@b1...> - 2009-05-14 13:19:26
|
On Thursday 14 May 2009 02:32:35 pm Patrick Ohly wrote: > You might have seen the news on LWN.net: > http://lwn.net/Articles/333059/rss > http://lwn.net/Articles/333157/rss > > Synthesis, a commercial implementation of SyncML client and server > technology, is now open source (LGPL). SyncEvolution, originally my > spare time project, has been my full-time job at Intel since the > beginning of this year. Part of that work was the migration of > SyncEvolution to Synthesis and preparing this launch with them. Congratulation for the release! I'm quite sure this a big win for the Open Source Community and SyncML driven technology in general. I hope this helps that SyncML turns into a primary-used Synchronization standard and avoids that more and more reinvented-wheel- synchronization-protocols (and especially without open standards) pop up. And my impression from the Synthesis developers is that they really focus on a interoperable SyncML stack - which is a very good thing! > > We couldn't talk about this publicly for a long time, much longer than I > had hoped, because of various legal issues and approvals that had to be > sorted out. However, we contacted Daniel and Michael in January and > discussed collaboration opportunities. My participation on the list > about data conversion aspects was a result of that. Finally, i can talk again without tainting people with confidential stuff ;) Btw. lots of people contacted my already regarding this announcement - so your PR works pretty well. (Expect heise.de which stated SyncML as a standard for synchronization PIM-only ;/) > > However, I'm still not sure what OpenSync really is going to do > regarding data conversion and how much the source code in libsynthesis > will help. I also don't have time to participate in further discussions, > so I'm afraid all that can be offered at this time is the invitation to > look at the source code and provide patches if you need additional APIs. > Currently, data conversion is tied into a sync session context and using > it is not as easy as it could be (see sysync::DataConversion() for a > starting point). Ok, thanks i'll have a look into once i have more time working on OpenSync again. Got my git clone yesterday already ;) JFYI, for all the other OpenSync developers. There were some discussion with Synthesis Developers and they provided us with some information how they solve the capabilities issues and how they do format conversion between the different vFormats. Which sound very interesting. Michael and me haven't seen the code before it got released under an Open Source license, to avoid that we get tainted (and might harm our future upstream development in libsyncml/OpenSync). But there were some discussion to might isolate some vFormat-Handling code and turn this into a libVxx. I hope there is still some interest in looking into that. (Maybe Lukas or Beat can use this opportunity to advertise your code - and why it might be better then our XMLFormat-approach ;) Yeah, and this is also the reason why i tried to make OpenSync more independent of XMLFormat. I guess libsynthesis Format handling code already deals pretty well with Timezones and all kind of Recurrence Rules which are out in the wild. Since, our xmlformat schema isn't final yet - and missing definition likes Timezone. Maybe we should looking into libsynthesis (or libVxx) and evaluate quickly if this codebase should be our primary common-format to deal with PIM data. (libsynthesis also has some common-format, which they use when converting from vcalendar to icalendar) We still can provide format-plugins which convert between xmlformat and the new libVxx common-format. So we don't break support for plugins which are still directly rely on XMLFormat (but as i stated in the past they should try to avoid direct dependency to XMLFormat - so we can easily replace XMLFormat with something like libVxx) [...] > Because there is clearly urgent demand for it, we have to look at adding > the server mode to SyncEvolution+Synthesis and cannot wait for OpenSync > to fill that space. It's also less work for us to take that route. Patrick, are you talking about SyncML Http Server or SyncML OBEX Server? Or both? IIRC, last time we talked there was only the plan for HTTP. Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D |