Re: Synthesis open source, provides data conversion (kind of)

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: gollub@...          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


------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel