> 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?
I had sent the patches more than a few months ago to the libwbxml maintainer and he acknowledged that he had received them. I still don't see any updates to his SVN respository, though. Given that John Carr is working on a wbxml <-> XML converter in Python, that might be the best way to go. > > 2) 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. Makes sense to me. I agree with you that wbxml stuff should remain in sync-engine. > 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. > > ... snip ... > > 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...... That's great that you were able to trace through all of this. I'm also happy to see that (at least it appears) that they ahve been making some significant improvements on the OpenSync side :) -- Richard Alimi Department of Computer Science Yale University
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
