<div dir="ltr">Oops don't mind. That mail should have been sent to my colleague =)<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Sep 8, 2013 at 3:16 AM, Daniel Morlock <span dir="ltr"><<a href="mailto:daniel.morlock@gmail.com" target="_blank">daniel.morlock@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">FYI<br></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Mon, Sep 2, 2013 at 9:35 AM, Thomas Brüderli <span dir="ltr"><<a href="mailto:bruederli@kolabsys.com" target="_blank">bruederli@kolabsys.com</a>></span> wrote:<br>


</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Daniel Morlock wrote:<br>
> Hi,<br>
<br>
Hello Daniel<br>
<div>><br>
> I'd like to add support for adding/modifying public and private iCal<br>
> calenders within Roundcube's calendar plugin e.g. Google's Holiday<br>
> calendar. Did I get it right, that there is not yet any support to<br>
> integrate iCal calenders in such a way?<br>
<br>
</div>Great! And yes, there's no support yet for this. But we already have a<br>
ticket for this feature request:<br>
<a href="https://issues.kolab.org/show_bug.cgi?id=2007" target="_blank">https://issues.kolab.org/show_bug.cgi?id=2007</a><br>
<div>><br>
> If yes I'd try to extend the calendar plugin to enable iCal client<br>
> support. A first attempt would be:<br>
><br>
> - Create another calendar driver that uses iCal as storage backend.<br>
<br>
</div>I suppose that would include some local caching, right?<br>
You could consider to use the yet existing database driver for this.<br>
That already lets you store events in the local database and to query<br>
them (e.g. by date range).<br>
<div><br>
> - Modify calendar class to support multiple drivers.<br>
<br>
</div>That's a rather complicated task because it requires major changes in<br>
the core architecture of the plugin.<br>
<div><br>
> - Extend frontend to add/remove public and private iCal calendars.<br>
<br>
</div>Sounds good. We already have a dialog for adding/editing calendars which<br>
can show driver-depended input fields. Just add an URL and refresh<br>
interval to that dialog and you're good.<br>
<div>><br>
> Is there an existing iCal client library that I can use for the calendar<br>
> driver?<br>
<br>
</div>Yes there is since the calendar already supports iCal import and export.<br>
The latest git master version now uses the Sabre VObject library for<br>
this. The module is "hidden" in the libcalendaring plugin which collects<br>
basic calendaring functions that are used by several plugins. Just check<br>
the calendar's import function and you'll find out how to use the iCal<br>
parser.<br>
<div><br>
> Any thoughs how to enable support for mulitple calendar drivers?<br>
<br>
</div>That's definitely the trickiest part of this. An event is usually<br>
referenced by the calendar ID + event ID. This probably needs to be<br>
extended by adding the driver name. As an alternative, you could add<br>
some magic keyword to the calendar ID which identifies the driver that<br>
provides the calendar resource: e.g. "kolab:The/Calendar/ID" or<br>
"ical:2234". This way, you wouldn't need to touch all the places where<br>
the calendar ID + event ID tuple is submitted.<br>
<div><br>
> Any other suggestions or ideas concerning this topic?<br>
<br>
</div>A more straight-forward but probably less sustainable approach would be<br>
to handle such read-only iCal calendars inside the Kolab or Database<br>
driver without adding the multi-driver logic. For the Kolab driver that<br>
would be relatively easy because each calendar resource is already<br>
represented with a separate instance of class kolab_calendar. You could<br>
implement a kolab_icalendar class with the same interface and create<br>
instances for every subscribed iCal feed when building up the<br>
$this->calendars list.<br>
<br>
But as said, this would be the quick-and-dirty hack and only works<br>
nicely with the kolab driver. Of course we're seeking for a more general<br>
approach that would add this feature to the database driver as well.<br>
<br>
Please keep posting your thoughts and ideas for this either to this<br>
mailing list or to the Bugzilla ticket mentioned above.<br>
<br>
Thanks!<br>
<br>
Thomas<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@lists.kolab.org" target="_blank">devel@lists.kolab.org</a><br>
<a href="https://lists.kolab.org/mailman/listinfo/devel" target="_blank">https://lists.kolab.org/mailman/listinfo/devel</a><br>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div></div></div>