[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 21:09:40
Message-ID: 200504141709.40617.winter () kde ! org
[Download RAW message or body]

On Thursday 14 April 2005 04:53 pm, JP Rosevear wrote:
> 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).
> 
Errr.. so IOW you are advising an immediate revert??

> 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.
> 
So kdepim and evolution are stuck at libical 0.23 forever??
Gulp.


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