Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Daniel Gollub <gollub <at> b1-systems.de>
Subject: Re: Synthesis open source, provides data conversion (kind of)
Newsgroups: gmane.comp.misc.opensync.devel
Date: Thursday 14th May 2009 13:16:03 UTC (over 8 years ago)
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@b1-systems.de          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
 
CD: 3ms