[CalendarServer-dev] Write Locks and Unmapped URLs

Helge Heß me at helgehess.eu
Mon Apr 7 13:11:02 PDT 2008


On 07.04.2008, at 21:54, Michael Rasmussen wrote:
> According to RFC4918 (June 2007) Adding a calendar resource could  
> cause
> a lost-update so clients are advised to use on of the following  
> scheme:
> 1) If lock is supported request a lock on and Unmapped URL
> 2) If lock is not supported use the header If-None-Match (RFC2616)
>
> As I see it using If-None-Match header is more flexible and requires
> less from both client and server. My question is then: Are there any
> added benefit from using a Lock on and Unmapped URL if the server
> supports locking or should I use If-None-Match header anyway?


I'm not entirely sure what your question is. Especially your point 1)  
sounds incorrect. I don't think you can get a lock on an umapped-URL.  
You would need to lock the whole collection, then fetch all contained  
names, then create the item, then unlock the collection. Of course  
thats very expensive.

A LOCK can make sense on UPDATEs if you have a simple client which  
can't deal well with conflicts. LOCK, GET, show, make modifications,  
PUT, UNLOCK. This should never produce a conflict.

There are also a few situations where it can improve usability. Eg if  
the user opens an event editor panel in online mode, it can be quite  
good to issue a time constrained LOCK (a minute after each onchange- 
event or so ;-). This way you can reduce likelyness of conflicts a  
lot. (you still would not _rely_ on the LOCK, just add a bit of  
semantic information on the resource editing status).

BTW: such generic questions are better placed on the CalDAV mailing  
list:
   http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

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


More information about the calendarserver-dev mailing list