[dev] iCalendar stuff

[Karsten Fourmont]

Hi,

I intend to make some changes to the Horde::Data and the iCalendar package.
Here's some information in advance for those who are interested.

Currently parsing/generating of iCalendar data is done in the Horde::Data
package as well as in the iCalendar package. This should be unified to one
place, namely iCalendar. iCalendar's parsing is more stable and seems to
handle recurring events as well. See bug
http://bugs.horde.org/details.php?id=86.

Things to do:

1) make Horde::Data use the iCalendar package for the generating/parsing of
vcalendar data. Basically this means: the helper class Data/Data/imc.php has
to go.

2) while I'm at it I'd like to clean up the iCalendar package itself a bit:
currently the subclasses (valarm, vevent etc.) in iCalendar/iCalendar/*.php
contain a reference to an Horde_iCalendar "container" object, which has to
be provided when calling the constructor. This is inconvenient (for example
vnotes are not normally enclosed in an vCalendar container) and
unneccessary: to add an object to a container, you have to call
Horde_iCalendar::addComponent anyhow. So that would be the appropriate place
to set the child's _container element. So I'll remove the constructors with
container arguments and make the child's container var be set in
Horde_iCalendar::addComponent instead.

3) Horde, Nag, Kronolith and (later) Turba will get fromiCalendar /
toiCalendar functions. That's mostly done already, but Kronolith's Event
already has an old toiCalendar function. This functions does not return an
iCalendar object but a simple hash array and also requires an uncessary
Horde::Data vcalendar object as parameter which is only used to call the
static makedate() method. I'd like to remove the parameter and rename the
function from  "toiCalendar" to "toArray" (as that's what it does) and
instead rename the (by now existing) "tovEvent" function to "toiCalendar" to
keep things consistent. I'll update all the places where these things are
called throughout the Horde CVS of course.

4) somewhat related: currently the Api import functions (like
kronlith/lib/ap.php:_kronolith_import) honor external UIDs during import. So
when you import an event like "BEGIN:VEVENT\nUID:gargamel\nSUMMARY:strange
guid\nEND:VEVENT" you end up with an event_id gargamel in your
kronolith_events table. That's bad. Nobody should be able to dictate us our
primary keys. I think that's also the reason for bug
http://bugs.horde.org/details.php?id=368. I'd like to modify the _import
functions to completly ignore external UIDs.

Any thoughts, comments or objections? Otherwise I'll just go ahead and
do/commit these changes.

Cheers,
 Karsten