[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:       2004-09-01 4:24:38
Message-ID: 1094012678.20762.40.camel () bishop ! rosevear ! com
[Download RAW message or body]

On Mon, 2004-08-30 at 21:57 +0200, Helge Hess wrote:
> On Aug 30, 2004, at 21:40, Dan Winship wrote:
> > (Our plan was to do something GObject-based, to use the existing GNOME
> > bindings-generating machinery, like we already do for EVCard.)
>
> Hm, so I guess that this will actually happen:
>    GNOME: GObject based iCal lib
>    KDE:   C++ based iCal lib
>    OGo:   Objective-C based iCal lib (already available, but untested)
> 
> Since I think that all developers prefer their "own" environment to fix 
> the annoying libical issue ;-) Is there any chance (or reason) to avoid 
> that and do something together in plain C?

Possibly, but I can only imagine this being a longer term project. 

As Dan alluded to, most of the policy resides in Evolution any how (how
is it in other apps?), so for us libical is mostly a parser, we even
have our own recurrence expansion engine already (the libical one was
insufficient when we first started using it) and we wrote the timezone
support initially (which is borked in cvs libical).  Being as its only a
parser to us and we have a similar one for vcards already, I don't feal
overly compelled

Things that might push me to a shared development lib would be:

1) Usefulness of being the default free software implementation when
interoperability issues arise.

2) Actual adoption of CAP, since that is a lot more complex to
implement.

3) More policy, ie enforcement of Property restrictions on objects (ie
removing the dtend property when a duration property is set on a
VEVENT).

Sebastien's arguments are well understood and valid but the inherent
benefits don't come into play if the replacement is simply an iCalendar
parser with the extra work that is implied to write basic things like
linked lists if the library is to be used by all at the lowest common
denominator.

> 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_?
> I think thats why Sebastian initially asked - on Debian he needs to 
> package a separate libical for OGo even though Evo and Kontact already 
> provide one (but apparently not as a small package, but somewhere deep 
> inside the environment).

I guess we could does this, we already install ours into a private
prefix to avoid conflicts, seems like a lot of work for little gain with
all the patches that would probably need to be merged.

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

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