Okay. I'll do so for now.
I don't think that requiring the PEAR package is a problem, but if 
there are clients that support PUT but not DAV, it might be worth 
supporting them.
I was referring to the $file_types array at the top of the patch.

I chose ics.php to be consistent for things like iCal and Kontact to 
use the same URL for publish and subscribe.  I spoke with Jan in IRC 
back when this ticket was opened.  It was his opinion that this was 
too hacky to be included and he pointed me to some work done to fully 
support CalDAV.  The CalDAV mechanism will also support the 
functionality that I enabled in ics.php.  As such perhaps this ticket 
should be cancelled.



The only real redeeming quality of this patch is that it supports 
publishing ICS without requiring DAV.  It's up to you whether this is 
something that Horde would want to support.  I got the impression that 
future releases of Horde will drop ics.php in favor of the CalDAV 
access (it appears to be backwards compatible with the ics.php 
functionality), but does add a dependency on WebDAV PEAR libs being 
installed.



Regarding CSV did you mean ICS?  I did not do anything to support CSV 
in my patch.

Why are these changes to ics.php instead of to data.php, given the 
mention of CSV and the fact that most of the code looks much more 
similar to data.php?

I did see it but the ticket hadn't been updated in a few months and 
seemed to have some remaining unanswered questions.



Also:

* This version doesn't rely on HTTP_WebDAV_Server

* I like the ideal of supporting true WebDAV rather than this in the 
long run.  However the WebDAV support in Horde does not yet appear to 
be working yet, or will be in the near term.  When it is I think using 
/rpc.php/kronolith is the way to go, replacing all of the 
functionality in ics.php (and deprecating it entirely).

You know that there already exists a more complete patch for that 
feature? See ticket #3032.

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.