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

List:       kde-pim
Subject:    Re: [Kde-pim] ical handling library
From:       Helge Hess <helge.hess () opengroupware ! org>
Date:       2004-09-02 0:47:25
Message-ID: A8AD90AC-FC79-11D8-80FD-000D93C1A604 () opengroupware ! org
[Download RAW message or body]

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.

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

_______________________________________________
kde-pim mailing list
kde-pim@mail.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]