Re: [Kolab-devel] Extending Calendar Plugin

Oops don't mind. That mail should have been sent to my colleague =)


On Sun, Sep 8, 2013 at 3:16 AM, Daniel Morlock <[email protected]>wrote:

> FYI
>
>
> 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?
>> 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
>>
>> _______________________________________________
>> devel mailing list
>> [email protected]
>> https://lists.kolab.org/mailman/listinfo/devel
>>
>
>

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