[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] OpenSync
From:       Armin Bauer <armin.bauer () desscon ! com>
Date:       2005-06-10 10:29:45
Message-ID: 42A96B99.9050706 () desscon ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Till Adam wrote:
> On Friday 10 June 2005 11:56, Reinhold Kainhofer wrote:
>
>>On Friday 10 June 2005 11:54, Till Adam wrote:
>>
>>>On Friday 10 June 2005 11:21, Armin Bauer wrote:
>>>
>>>>Reinhold Kainhofer wrote:
>>>>
>>>>>Am Donnerstag, 9. Juni 2005 23:48 schrieb Eduardo Pereira Habkost:
>>>>
>>>>Yes and no. The format conversion for a sync between a palm and KDE
>>>>would look like this:
>>>>
>>>>palm <-> palm-specific format <-> xml-format <-> vcard <-> kde
>>>>
>>>>So we use an intermediary xml format which is used as a central point
>>>>for all the conversions. This format would have to support a merging
>>>>operation. By "merging operation" i mean that opensync gets as input:
>>>
>>>Before you create a new XML based format, might I suggest you look at the
>>>one specified by and for the Kolab project, which enables us to
>>>interoperate between different Kolab2 clients reading and writing the
>>>same folder.
>>
>>Till, no offense, but I don't think the kolab format is suited as a data
>>structure for a syncing application, that needs to include every possible
>>field that any device might provide. The kolab format is specified for
>>events/to-dos/contacts/etc., but OpenSync is supposed to work with generic
>>objects.
>
>
> Ok.
>
>
>>Furthermore, the kolab format e.g. doesn't fully support recurrences for
>>events (rdates!!! exrules, arbitrary rrules etc.) and arbitrary custom
>>fields (does kolab support custom fields at all???)
>
>
> Yes, the recurrence handling is as of yet underspecified. That should not
> disqualify the format as a base for further refinement, though, I think?
>
> As for custom fields, sure, any client can add custom tags, all clients are
> required to treat them transparently and not touch them.
>
> I'm obviously not deeply involved with this discussion, nor do I have any
> inclination to get anywhere near syncing, my life has unpleasantness enough
> already, I just thought I'd throw in the Kolab format as something to look
> at. :)
>
> Till

Actually the format you are using is fairly similar to our xml formats
of contacts. But i think reinhold is also right. Our xml format must be
able to support any possible format (for example if evo2 adds a new
field in the future like x-spouses-shoe-size). So we have to make sure
that the format is changeable very easy without having to be afraid that
we might break a standard defined somewhere.

But i think it would be easy to write a converter from our format to
your format (maybe using xslt?) so that we can teach opensync to speak
your format. (opensync is also capable of doing path searches with
format conversions. so if we had a converter from our xml format to
yours and you have converters from yours to other formats like mapi,
opensync would directly be able to convert to the mapi format)

But we might have to change our format anyways in the future to be
better able to support merging operations. So we have to make sure that
the xml format of the data and the xml format of the device capability
information can be combined very easy to calculate the merge.

>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> kde-pim mailing list
> kde-pim@kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> kde-pim home page at http://pim.kde.org/

["signature.asc" (application/pgp-signature)]

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]