[dev] Implementing HTTP PUT

[Håvard Wigtil]

When I last wrote that my patches would give a working CalDAV server
that wasn't entirely true, I forgot that I hadn't posted any working PUT
patch yet.
(The quick and dirty hack that I used for testing was "elseif
(count($parts) == 2) { return _kronolith_import($content,
'text/calendar', $parts[0]}" at the end of _kronolith_put in
kronolith/lib/api.php.)

As far as I know PUT is only implemented for Kronolith, and only
for .ics files (i.e. a whole calendar at a time).
I'd like to work on extending this, and would like your opinions on a
few points. I'm hpoing someone can answer at least the first question,
as will determine how I'll try to implement this.

1) Is it preferable to implement as much as possible in each
application, or should as much as possible (that relates to WebDAV) be
implemented in webdav.php. I'm asking because for PUT so far most of the
implementation is in the Kronolith API, but I think it makes more sens
to have the bulk of the implementation in webdav.php. As far as I can
tell the implementation will be mostly similar between applications.

2) Is there any policy for adding new API calls? If I go for an
implementation in webdav.php I'll probably need at least an API method
to tell me if a given UID exists in a given collection (unless there is
something I can use that I've overlooked).

3) And is there any reason that the different APIs have methods like
"listCalendars" and "listTasklists" instead of "listCollections", so
that they can be used without having conditionals on the application
name?

4) I've also wondered a bit on how PUT should be implemented in terms of
file names. From reading the HTTP 1.1 spec it seems like the server must
accept the given file name or issue a "301 Moved Permanently" reply. See
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6, "If the
server desires that the request be applied to a different URI, it MUST
send a 301 (Moved Permanently) response; the user agent MAY then make
its own decision regarding whether or not to redirect the request."
But there is also the Location header, and it seems like it can be used
in reply to PUT:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30.

Any opinions on how to understand the spec? Should Horde accept the new
file name (and use it as a UID in the database / storage). Should the
request for a new item with a UID that doesn't fit the storage scheme be
answered with a 301 response? Or should a new entry (file name) be
created and the name returned in the Location header?

--
Håvard Wigtil || http://wigtil.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt signert meldingsdel
Url : http://lists.horde.org/archives/dev/attachments/20061204/3074b6c8/attachment.bin