Just to summarize what we talked about in IRC the other day with my understanding of the situation right now...
We use libversit in 2 places. It is in the Evolution plugin, but I don't think it is required (at least not any more). The Evolution plugin doesn't call it directly - it actually makes a few calls to libical (includes ical.h). The libversit in multisync/src is currently only being used by the Opie plugin. I have modified it so fix some bugs and include support for recurring events, alarms, etc. When I started the Opie plugin this past winter I did not know anything about parsing iCal/vCal/vCard and I turned up libversit after some searching. I modified it to do what I needed. I agree that we should be using libical for calendaring/todos and libversit for vCards. The libical API looks much nicer, and will probably provide more features. There are a few problems: 1. Rewriting opie_vtype.c to use libical will take some work and a lot of retesting to make sure I don't break anything. 2. As Mika Raento mentioned, there is a libical-evolution in use by the Evo plugin. We either have to use it or end up with symbol conflicts. 3. libical isn't shipped by all distributions. It doesn't seem to be in RedHat, although it looks like it is in Debian (unstable anyway). Thanks for you help with this Hub. Tom On Wed, 2003-09-24 at 09:42, Hubert Figuiere wrote: > Hi, > > I have dug into the multisync source code, solely for curiosity. > > I found out that you use libversit to parse vCalendar version 2.0, aka > iCalendar (RFC 2445). I must say that this is a really bad idea as > libversit only knows about vCalendar 1.0 that diverge enough from 2.0. > That include recurrent events (seems to be reading lot of problem > reports with that), encoding (vCalendar 1.0 as not been designed with > non-ASCII charset in mind). May I suggest to switch to libical and use > vCalendar 2.0 internally for any calendaring / todo information ? This > is already what Evolution uses. > > libical: > http://www.softwarestudio.org/libical/ > > The benefit would be: standard data model for calendaring, that handles > all what we'd want. > Then any device emitting vCalendar 1.0 calendaring info would just need > conversion to iCalendar before sending to the sync engine. (libicalvcal > in libical is meant to do that, but it is hackish). > > Correct me if I'm wrong. > > Hub ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Multisync-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/multisync-devel
