[Tickets #4193] NEW: Allow publishing via iCalendar

bugs@bugs.horde.org bugs at bugs.horde.org
Sun Jul 23 00:20:39 PDT 2006


Ticket URL: https://dev.horde.org/horde/whups/ticket/?id=4193
 Ticket             | 4193
 Created By         | Ben Klang <ben at alkaloid.net>
 Summary            | Allow publishing via iCalendar
 Queue              | Kronolith
 Version            | HEAD
 State              | New
 Priority           | 1. Low
 Type               | Enhancement
 Owners             | 
+New Attachment     | kronolith-publish-ics.patch

Ben Klang <ben at alkaloid.net> (2006-07-23 00:20) wrote:

This patch makes it possible for iCalendar clients (tested with Apple iCal
and KDE Kontact/KOrganizer) to publish their calendars to Kronolith using
the ics.php.  The logic was taken largely from the data.php import

1) The calendar is published with an HTTP PUT.  This requires server
administrators to allow PUT to the file ics.php before this will work. 
Here is an example Apache httpd.conf stanza:
<Files "ics.php">
    <LimitExcept GET PUT>
        Order Allow,Deny
        Allow from all
This block must either go in the .htaccess file in the kronolith directory
or inside a <Directory> block in the main httpd.conf

2) Apple's iCal assumes a that the calendar will be published to a
directory.  To make this work with Kronolith, a little mod_rewrite magic
is necessary.
The Kronolith directory must have Options +SymLinkIfOwnerMatch (this is
necessary for mod_rewrite):

RewriteEngine On
RewriteRule ^ics.php/(.*).ics$ ics.php?c=$1 [L,QSA]

These two lines can go in either of the locations as above.
When configuring the name of the calendar to publish in iCal set it to the
Kronolith calendar name.  For regular user calendars this will be their
Horde login.  For shared calendars it will be the long UUID of the
calendar.  The name of the calendar from iCal's perspective is what is
passed to ical.php as the 'c' variable.

Kontact/KOrganizer can use this same convention or can specify the direct
URL (such as ics.php?c=userid).  Note also that Kontact requires the Horde
username and password to be embedded in the url

3) Because HTTP PUT is used, the patch "tricks" Horde into thinking a file
was uploaded by the browser.  Normal HTTP POSTs with form-uploaded files
get intercepted by PHP and stored into a temporary location accessible
later by the script.  Instead this patch does that work and populates the
PHP global variables manually as PHP would have done itself had it handled
the file upload.  There may be a better way (I couldn't think of one at the
time) but this mechanism works very well.

4) iCalendar is NOT a synchronization protocol! Because of this each time
the calendar is updated the entire calendar is uploaded.  If two users are
uploading calendar events a potential race condition exists where the first
user's updated events get deleted or replaced by the second user.  This
should never occur if the calendar is only ever updated by a single client
at a time so I believe this is a useful patch but the danger must be
understood.  If multiple clients are to be used on the same calendar it's
imperative that they take all precautions to syncrhonize manually before
publishing events.

While there are potential pitfalls I think the patch still has value.  For
many home or small-installation users the ability to publish a calendar via
readily accessible tools such as iCal or Kontact/KOrganizer is an excellent
way to keep track of calendar events.  For largers groups CalDAV, GroupDAV
or CAP are much more desirable (and complex) alternatives.

More information about the bugs mailing list