[dev] iCalendar stuff

[Karsten Fourmont]

Hi,

thanks for the response.

[ 1) get rid  of imc.php ]
> For Horde_Data_icalendar, yes, but not in general (yet) - it's still used for
> the vcard parser.

Sure. vcard and turba have to be converted as well at some point in
time. That's just something I'm not ready to deal with (yet). So for the time
being, imc.php will stay.

[ 2) make _container optional in iCalendar subclasses ]

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

Sure. All this access is of the form
$this->_container->getAttribute('METHOD')
So we can just use a default (I think 'PUBLISH') when container is empty().

[ 4) ignore "UID:" in api import/replace or not ]
> 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.

hmmm. Just to get this straight. How do we deal with this in kronolith (others
are the same):

a) _kronolith_replace($guid, $content, $contentType)

this is supposed to replace an existing entry. The guid is explicitly
given as a parameter. What do we do if $content contains an "UID:" that is
different from $guid? Current behaviour is: UID overrides $guid. This most
likely results in a failed update attempt. (SQL update ...)

2) _kronolith_import($content, $contentType, $calendar = null)

here we're supposed to import a new event. Again: what do we do if a "UID:" is
specified in the content? What if this guid already exists? Replace the
existing entry? And if it exists in a different calendar?

I'm fine with any behaviour. Just enlighten me :-)

  Karsten