[Kolab-devel] Extending Calendar Plugin

[Thomas Brüderli]

Daniel Morlock wrote:
> Hi,

Hello Daniel
> 
> I'd like to add support for adding/modifying public and private iCal
> calenders within Roundcube's calendar plugin e.g. Google's Holiday
> calendar. Did I get it right, that there is not yet any support to
> integrate iCal calenders in such a way?

Great! And yes, there's no support yet for this. But we already have a
ticket for this feature request:
https://issues.kolab.org/show_bug.cgi?id=2007
> 
> If yes I'd try to extend the calendar plugin to enable iCal client
> support. A first attempt would be:
> 
> - Create another calendar driver that uses iCal as storage backend.

I suppose that would include some local caching, right?
You could consider to use the yet existing database driver for this.
That already lets you store events in the local database and to query
them (e.g. by date range).

> - Modify calendar class to support multiple drivers.

That's a rather complicated task because it requires major changes in
the core architecture of the plugin.

> - Extend frontend to add/remove public and private iCal calendars.

Sounds good. We already have a dialog for adding/editing calendars which
can show driver-depended input fields. Just add an URL and refresh
interval to that dialog and you're good.
> 
> Is there an existing iCal client library that I can use for the calendar
> driver?

Yes there is since the calendar already supports iCal import and export.
The latest git master version now uses the Sabre VObject library for
this. The module is "hidden" in the libcalendaring plugin which collects
basic calendaring functions that are used by several plugins. Just check
the calendar's import function and you'll find out how to use the iCal
parser.

> Any thoughs how to enable support for mulitple calendar drivers?

That's definitely the trickiest part of this. An event is usually
referenced by the calendar ID + event ID. This probably needs to be
extended by adding the driver name. As an alternative, you could add
some magic keyword to the calendar ID which identifies the driver that
provides the calendar resource: e.g. "kolab:The/Calendar/ID" or
"ical:2234". This way, you wouldn't need to touch all the places where
the calendar ID + event ID tuple is submitted.

> Any other suggestions or ideas concerning this topic?

A more straight-forward but probably less sustainable approach would be
to handle such read-only iCal calendars inside the Kolab or Database
driver without adding the multi-driver logic. For the Kolab driver that
would be relatively easy because each calendar resource is already
represented with a separate instance of class kolab_calendar. You could
implement a kolab_icalendar class with the same interface and create
instances for every subscribed iCal feed when building up the
$this->calendars list.

But as said, this would be the quick-and-dirty hack and only works
nicely with the kolab driver. Of course we're seeking for a more general
approach that would add this feature to the database driver as well.

Please keep posting your thoughts and ideas for this either to this
mailing list or to the Bugzilla ticket mentioned above.

Thanks!

Thomas