Tickets :: Comment on [#4193] Allow publishing via iCalendar

* Your Email Address
* Spam protection	Enter the letters below: .__ .__ .___. .. . [ __\| \ \| \|\ / [_./\|__/ \| \__\| \/
Comment	> 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 routine. > > > > Notes: > > 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 > > </LimitExcept> > > </Files> > > 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 > (http://user:pass@host/horde/kronolith/ics.php?c=userid). > > > > 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.
Attachment
Watch this ticket

Saved Queries