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/
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/calendarserver-dev
