Post by r***@velvetsea.netPost by Dr J A GowOnce the 0.3x plugin is working fully, one thing I am investigating in
the light of the changes in OpenSync's architecture is the way in which
sync-engine does its format conversions. For those who do not know,
OpenSync 0.3 spins off its format conversions into plugins. Currently I
am conducting a feasibility study in developing an OpenSync format
plugin with our AirSync<->XML format conversions in it, and subsequently
removing (or disabling) the format conversion code in sync-engine. This
would have a number of benefits: it would unburden sync-engine from
format conversions and allow it to speak native AirSync to the OpenSync
interface. Format conversions to OpenSync XML formats would then be
handled by the format plugin. This is more in keeping with the OpenSync
0.3x paradigm.
Such a format plugin should arguably be better residing in OpenSync SVN
as it would then expose the format to anything else out there that cares
to speak AirSync.
What do you all think about this approach?
I would very much like that :) Another issue with that approach, though,
is what to do with the libwbxml stuff. I somehow doubt that OpenSync
would want to introduce that dependency for their entire tree, so we'd
1) Implement our own wbXml stuff (perhaps borrow the required pieces from
libwbxml with appropriate credit given to the author - but we have to
double-check the licensing details of this)
I was thinking of leaving the wbxml stuff on the sync-engine side and
passing Airsync/XML to OpenSync - this way we keep binary formats such
as wbxml (specific to handhelds and similar) out of OpenSync. The
conversion between wbxml and xml is direct, whereas the conversion
between AirSync/XML and OpenSync XML requires more of a translation of
both elements and content.
Can we not get our wbxml patches accepted upstream so, from the next
major release of wbxml, we can just have the user pull in their
distribution's wbxml library?
Post by r***@velvetsea.net2) Ensure that OpenSync can have only a single format conversion plugin
have a dependency on libwbxml without requring that dependency in their
entire tree.
We could do this, but I would be keen on keeping binary formats out of
the OpenSync item sync pathway if for no other reasons than the inherent
'open-ness' of XML and not making the OpenSync components (including
format plugins) require a dependence on a third-party conversion
library.
Post by r***@velvetsea.netJohn and Mark: I'd like to echo everyone's thanks to you guys for
continuing to actively participate here. I would love to get back to it
(especially to implement that default timezone capability needed for
KDE-Pim) but unfortunately my schedule now and in the forseeable future
doesn't really permit it. Thanks again, though - you guys are great!
No problem - this is an interesting project to work on!
I perhaps should have posted earlier about that default timezone issue.
A while ago I generated some Python code that will extract the system
timezone from the binary Olson files and from this construct a ruleset
for use with the OpenSync XML (will need to update this for the new
OpenSync 0.3 schemas). However it was here I ran into an anomaly.
Consider a timezone such as UK/London. Capturing some of the XML coming
in from OpenSync showed that there were two clear rules, one for DST and
one for STD time giving the appearance that these were the only two
rules that had ever existed. Each section, (DST or STD) had a single
recurrence rule attached to it.
Now the Olson binary file actually contains a lot more information -
when I examined the output from the program I wrote there were actually
a number of differing rules for the start/stop of DST at different
points throughout history - i.e. more than just the two that seemed to
be provided with a typical OpenSync item. To correctly convert these
rules would require more than two simple rulesets governing DST/STD
transitions.
Not only that, but the rules directly obtained from the Olson database
conflicted with the rules provided with the typical item. Examination of
the binary timezone file confirmed that the output from my program was
correct - and that the simple two-rule output from OpenSync did not
match.
So I compared the two with the output from the 'vzic' program - a
utility that supposedly will generate iCal timezones from Olson files.
Both OpenSync and the vzic program gave a simple two-rule output which
did not match the content of the Olson binary rules!
Some basic searching shed no light on this, and without being able to
resolve this issue I did not fold the code into sync-engine at this
point.
I then had to turn attention to other matters.
However, the OpenSync 0.3x timezone rules seem to be a lot more
comprehensive and on the surface a lot closer to the Olson rules. I am
going to need to modify the timezone objects in sync-engine to handle
multiple recurrence rules in order to handle OpenSync 0.3x, and I will
hopefully be able to slip the default timezone generation code in at
this point with very little difficulty. So watch the 0.3x code very
closely......
John.