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

List:       kde-pim
Subject:    Re: [Kde-pim] ical handling library
From:       Allen Winter <winter () kde ! org>
Date:       2005-04-14 20:06:06
Message-ID: 200504141606.06211.winter () kde ! org
[Download RAW message or body]

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?

Regards,
Allen

-- 
Let's Keep the Political Talk Out of KDE PLEASE
_______________________________________________
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]