Re: [Opensync-devel] Getting things back on track

[Bjoern R. <bjo...@go...>]

> On Tue, 2009-10-20 at 09:55 +0200, Bjoern Ricks wrote:
>   
>> But as a developer of opensync I
>> can say that our framework supports (nearly) all use cases already.
>>     
>
> Do you support the use cases theoretically or in practice? My
> understanding is that "vCard 2.1 (phone) <=> vCard 3.0 (Evolution)" does
> not work. Nor does vCalendar <=> iCalendar. In my opinion the "future
> proofness" of OpenSync is mostly theoretical at this point. I'd be happy
> to be proven wrong, of course.
>   
That's a format dependent problem. In the past cstender kept an eye on
vformat. Of course there are issues with format conversion, because that
vcard, vcalender, ical, ... stuff is very complex too and every
application and device is handling it differently. But in opensyncs view
it is only a format and formats are separate plugins which provide
conversion routines. That should be relative easy for EVERY programmer
to fix if he knows some details of these formats.
>   
>>  I
>> don't think that SyncEvolution can handle different capabilities. 
>>     
>
> This is incorrect. Please have a look at
> http://syncevolution.org/development/pim-data-synchronization-why-it-so-hard
>
> It explains how the Synthesis engine uses capabilities to determine
> which properties are supported by a peer and how it generates that
> information automatically from the data format description. In contrast
> to other SyncML libraries, this intelligence is also available in
> clients, thus allowing a "smart" client to merge updates from a "dumber"
> server.
>
> For data source developers there's no need to do anything manually to
> use and support capabilities, in contrast to OpenSync and the Funambol
> client library.
>
>   
Sorry I shouldn't have written that line. I don't know SyncEvolution.
It's your baby and mine is opensync. Nothing else to say.

-- 
/Bjoern Ricks