Re: [Kolab-devel] Extending Calendar Plugin

Hi,

On Mon, Sep 2, 2013 at 9:35 AM, Thomas Brüderli <[email protected]>wrote:

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

Local caching seems tricky since it brings up a synchronization problem. So
I might skip caching in early versions but keep it in mind for the later
versions. Any suggestions about how to implement proper caching of iCal
calendars?


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

My first idea was to operate directly on the iCal server - so not doing any
local database operations at all.
Only purpose of the local database would be to store the URL's, usernames
and passwords of a user's subscribed iCal calendars.
Any thoughts?


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

I think I'm going to introduce a driver-identifier within the calendar ID
or use any similar so I don't need to touch all the mentioned places.


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

I also had that idea but discarded it since it looked like a
quick-and-dirty hack :-)


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

Sounds greats - let's do brainstorming in the mailing list. As soon as
thoughts turn into code I will start using Bugzilla.


>
> Thanks!
>
> Thomas
>
> _______________________________________________
> devel mailing list
> [email protected]
> https://lists.kolab.org/mailman/listinfo/devel
>

Thanks for help and advices!

Daniel.

_______________________________________________
devel mailing list
[email protected]
https://lists.kolab.org/mailman/listinfo/devel