[OGo-Developer] [Fwd: Re: Lightning daily built 30.9.2007 & OpenGroupware.org & CalDav]

[Helge Hess]

On 17.11.2007, at 21:59, Lars Schimmer wrote:
> 1) When I PUT a new resource into the store (using an 'If-None- 
> Match: *' header), I get a response of 200 Success. The way I read  
> the RFC, and the way the code is written, the response should be  
> 201 Created if the resource being PUT did not previously exist, and  
> 200 Success if the resource did previously exist and has been  
> successfully overwritten/modified. So Sunbird will consider a 200  
> on PUTting a new resource as an error (probable name collision).

2xx class codes all denote successfull storage, a 201 Created is  
certainly not required (nor widely implemented) for created items  
(though it makes sense [I think the difference is that 200 is  
supposed to contain a response body, but anyways]).

However the reasoning is incorrect in the first place, if there is an  
'if-none-match: *' it can *never* exist before. If it would, a 412  
status would be the result, never a 2xx.
And even if the 200 would imply that the resource did exist before,  
what then?? The old resource would have been overwritten! [havoc!!!]  
So the behaviour seems unreasonable.

Summary: 201 would be nice, 200 is perfectly OK and checking for 200  
vs 201 in the context of if-none-match is definitely wrong (if the  
server says 2xx the request definitely did succeed!).
=> OGo Enhancement (201 would be nice), Sunbird Bug (412 to ensure  
creations)


> 2) In order to minimize wire traffic, Sunbird is going to start to  
> cache item etags, so that when it needs to do a calendar query it  
> can first fetch only etags and second fetch new or changed items  
> with a multiget, pretty much as described in paragraph 8.2.1.3 of  
> the spec. OGo does not seem to support that initial <D:getetag>  
> query, which pretty much spoils the party.
>
> I don't know where to report such issues, and hope I can do so  
> through you.
>
> I very much appreciate access to the server, and will try to  
> include OGo as I test future Mozilla calendar CalDAV patches.

Correct. OGo does not really support CalDAV REPORT requests (yet).  
But it would be nice if Sunbird could fallback to multiple GETs if  
multiget is unavailable (CalDAV vs GroupDAV). Thats not really hard  
and enables plain WebDAV servers as backends (certainly a viable goal!).

Summary: missing CalDAV support in OGo, required REPORTs needs to be  
added. Would be nice if Sunbird would perform reasonable fallbacks to  
plain WebDAV.

Thanks,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/