[dev] Implementing HTTP PUT

[Jan Schneider]

Zitat von Håvard Wigtil <havardw at pvv.org>:

> 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.

This has to be decided case by case. Obviously it's generally favoured  
to have code in one central place instead of in many duplicate places.  
But this is still sometimes necessary to keep BC or for other  
technical reasons.

I don't see much code in _kronolith_put, so I'm not sure what you're  
talking about. As a rule of thumb, I'd say that all protocol and  
path-to-application-conversion should go to webdav.php, the actual  
data "putting" into lib/api.php.

> 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).

You could call the export method and see if it returns something.  
Otherwise we would have to add "exists" methods to the APIs.

> 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?

That's what "browse" is for.

> 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?

GroupDAV explicitely supports redirections when putting new objects to  
a collection. I don't know off my head how CalDAV handles this, but  
you should really look into that spec, not the general HTTP specs.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/