[dev] iCalendar stuff

[Chuck Hagenbuch]

Quoting Karsten Fourmont <fourmont at gmx.de>:

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

For Horde_Data_icalendar, yes, but not in general (yet) - it's still used for
the vcard parser.

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

Okay by me assuming it doesn't hit any snags along the way. There are a few
places where the children assume access to a container; error handling should
be added there.

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

Great.

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

We can't completely ignore them - that'd break iCalendar updates. We 
need to not
use external UIDs as the primary key, but we *do* need to maintain a 
map of the
original external UID.

-chuck

--
"Regard my poor demoralized mule!" - Juan Valdez