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/