With the final commit today to prevent deleting entire tasklists I 
consider this issue closed.

Yeah, that's what I meant about uploading individual .ics files - not 
clear. I guess those aren't technically .ics files either.

I got a note back from Hartmut indicating this bug is now fixed in PEAR CVS
Uploading a single .ics does work with the code in CVS right now as 
that is what I primarily tested.  There are two things left:



1) Fully test PUTting individual tasks into the tasklist folder.  I 
think mrubinsk may have tested this a bit but I haven't yet myself.



2) Deny deleting the .ics file or tasklist folder itself.  Based on 
testing feedback and conversations in IRC the ability to delete an 
entire tasklist from WebDAV will probably end up being more confusing 
for users than useful.  This should be the case at least until we get 
tasklist creation working either by creating a folder or by PUTting a 
new .ics file.  We will still allow deletion of individual tasks 
within the tasklist folder though.



Both of those items are fairly straightforward though so barring any 
more bugs we should be able to close this one pretty quickly.

What's left here? the HTTP_CONTENT_LENGTH issue is a bug in 
Http_WebDav_Server, so that doesn't need to hold this up.



Also, do we want to/can we support uploading of single .ics files to 
replace/add individual tasks in put()?

...and to clarify, the issue mentioned below regarding 
HTTP_CONTENT_LENGTH is still an issue. I can't upload the tasklist 
unless I comment out that block in HTTP/WebDAV/Server.php

OK. I think i was misunderstanding what to test.  I was downloading a 
task list, deleting it, then trying to upload it. That fails, but if 
rename the task list I'm uploading to an existing one, it works, and 
replaces the existing one.



So, delete works, and put works, but not directly after one another :)



(The MKCOL error still occurs, but only when trying to upload a 
directory of *.ics task files, or create a new directory)

Ideally yes, but wouldn't we need to support arbitrary share_names first?

What I'm seeing right now is:

1) When PUTing a file, pear's HTTP_WEBDAV_Server is chocking in 
http_PUT(). The switch block that checks the headers encounters a 
HTTP_CONTENT_LENGTH header that drops in to the default case and 
returns a 501 error.



2) Commenting out the default case let's me get passed that error, but 
then I get an error from nag that says the task list does not exist or 
I don't have permissions to modify it.



Still digging...

One other question came up:  Do we want to allow automatic creation of 
tasklists if a .ics file is uploaded or a directory is created for a 
non-existing tasklist?

I have now made all the necessary changes to allow PUT to work via 
WebDAV as well as of HEAD nag/lib/api.php version 1.167.



mrubinsk:  I could not recreate the behavior you saw with MKCOL.   
Would you retest and let me know if it's still a problem?



At this point browse, put, and delete seem to be working, at least for me.

OK. The deletion issue is fixed. We weren't checking for the .ics 
extension before comparing, and we were passing the share name instead 
of the share_object to removeShare().



The issue of creation is still problematic. The underlaying issue is 
that RPC/webdav.php is attempting to call a _nag_mkcol api method 
instead of _nag_put when adding an entire task list.  Trying to add a 
single task into an existing task list folder gives no errors, but 
silently fails.

Testing DELETE yields permission errors:



When deleting the .ics file, the issue is in the api code (around line 
659) when we test $parts[1] - it contains the '.ics' extension so the 
compare fails.



Once we're past that, that task items appear to be deleted, but then a 
"Shares must be Horde_Share_Objects or extend that class" error being 
returned I'm guessing on line 681 of api.php



Too late for me to look further though ... gotta get to bed :)

I will work on this issue.



One thing to note:  This change will break some aspects of backward 
compatibility with Horde 3.1/Nag 2.1.  In the case where a requested 
URL is the old style ("/rpc.php/nag/userid.ics" or 
"/rpc.php/nag/tasklistID.ics") we can serve up the task list.  However 
if someone tries to browse their own task list entries it will 
conflict with the new schema.  Example:



Nag 2.1: "/rpc.php/nag/userID-as-tasklistID"

Nag 2.2: "/rpc.php/nag/userID/userID-as-tasklistID"



In the interest of keeping the code simple I will not attempt to 
handle old-style requests to get task list items by browsing the task 
list ID as it was done in Nag 2.1

See bug 3032 and 
http://lists.horde.org/archives/cvs/Week-of-Mon-20080407/077263.html



From Jan:

Calendars in Kronolith for example are available now as:



/kronolith/owner/calname/event

/kronolith/owner/calname.ics



The idea is a) to have more structure, but more important b) to later   
  allow to create shares/resources from WebDAV (CalDAV) actually. To 
avoid share name clashing we discussed that users can create those 
share, but they will be prefixed with the user name. The WebDAV 
structure is going to do something similar. We could maybe even add 
some black magic to automatically strip and the user prefix from/to 
share names when displayed/added through the DAV interface.