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

List:       kde-pim
Subject:    Re: [Kde-pim] ical handling library
From:       JP Rosevear <jpr () novell ! com>
Date:       2005-04-14 20:53:15
Message-ID: 1113511995.8078.80.camel () bishop ! rosevear ! com
[Download RAW message or body]

On Thu, 2005-04-14 at 16:06 -0400, Allen Winter wrote:
> On Wednesday 01 September 2004 08:47 pm, Helge Hess wrote:
> > On Sep 1, 2004, at 19:07, Reinhold Kainhofer wrote:
> > > In KDE we currently use libical only as a parser for ics files, and 
> > > then
> > > create our own C++ objects from the data that we get from libical. Like
> > > evolution, we also had to implement the recurrence calculator ourselves
> > > (although ours is a nasty piece of code and needs to be cleaned up a 
> > > bit some
> > > time).
> > 
> > OK. Summary on that: all projects use libical only as a parser (for 
> > completeness: in OGo libical is also encapsulated as a SAX driver, 
> > higher level objects are ObjC).
> > 
> > I'm not an expert on iCalendar format parsing details, but I guess 
> > writing an iCalendar parser is more or less trivial 
> > (tagname;props:tagvalue\n), so it doesn't make a lot of sense to use 
> > something common?
> > 
> > A common higher level library is probably also out of question given 
> > that we all use different higher level environments (C++, GObject, 
> > Objective-C) and each environment has different conventions for 
> > calendaring relevant objects (say timezones or calendar data objects, 
> > or NSTimeZone, NSCalendarDate and NSTimeInterval in "our" language ;-). 
> > Not to speak of memory management etc.
> > 
> > > As far as the discussion about reviving libical goes: Who would be 
> > > willing to
> > > actively maintain that code?
> > 
> > I tend to be pragmatic on that. For whatever weird reason all projects 
> > currently _do_ use libical. This is the point which raised this thread 
> > ;-)
> > All have plans to fix that by creating something better than libical, 
> > but still use their private libical branch for several years.
> > 
> > So while I wouldn't expect any development on that libical, I would 
> > expect some legacy code sharing.
> > 
> > > Of course I'd like
> > > to have one library that will be used by all big PIM applications,
> > > preferrably in C++ (since that's the way I tend to think). I guess the 
> > > latter
> > > will not be possible, so KDE will need another wrapper library around 
> > > it
> > > anyway.
> > > This would increase compatibility across all applications using that 
> > > library,
> > > and all projects could profit from it.
> > 
> > Unlikely to happen. Who has the time/interest to do this? I guess none 
> > of us because it would imply reimplementing 50%+ of what is already 
> > available in the several core libraries.
> > 
> > I guess Evolution technology would be closest to this goal (being plain 
> > C), but probably require at least glib, which might be a no go for 
> > other environments (eg MozCal/Windows?), don't know (I guess it would 
> > be OK for OGo).
> > 
> > > > Besides what happens after Evo 2.0, Kontact 3.3 and OGo 1.0 - is there
> > > > any chance to put up a shared "legacy" libical for distributors _now_?
> > > libkcal (KDE's calendar library, which uses libical for parsing and 
> > > writing
> > > out ics files) statically links in its own copy of libical.
> > 
> > Hm, so static linking as the pragmatic solution. Should be the way to 
> > go.
> > 
> Helge, et.al.
> 
> Just to let you know that we just committed the "newest" libical (version 0.24 RC4) \
> which is a least 2 years old into kdepim.  I backported local KDE mods that were \
> less than 3 years old.. that were obviously correct fixes. I also ported a few mods \
> from Lutz Rogowski's kdepimpi project. 
> We'll find out how much breakage there is soon enough :)
> 
> We (opensource) really, really need a fresh new libical.   Does anyone know of  \
> active development projects in this area?

When Evolution did this timezone handling/conversion was blatantly
broken.  We copied the 0.23 stuff back in.  

Also the memory handling is atrocious with the fixed length ring buffer
of size 2500 and it does not handle older mozilla (and current) oracle
calendars if you try to pass them in as a whole (parser stops parsing at
the end of the first vcalendar instead of processing the rest).

There was some discussion of a new libical in this thread way back but
everyone mostly wants a parser that converts to their native object
system and so it was dropped as an idea.

-JP
-- 
JP Rosevear <jpr@novell.com>
Novell, Inc.

_______________________________________________
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]