Write Locks and Unmapped URLs
Hi again, 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? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Use uniform input formats. - The Elements of Programming Style (Kernighan & Plaugher)
Hi Michael, --On April 7, 2008 9:54:38 PM +0200 Michael Rasmussen <mir@datanom.net> 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?
If-None-Match is probably best right now. I think LOCK is more useful when you need to make multiple updates and ensure those are consistent. -- Cyrus Daboo
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/
On Mon, 7 Apr 2008 22:11:02 +0200 Helge Heß <me@helgehess.eu> wrote:
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.
Maybe it is just me who has over interpreted it, but AFAIK RFC-4918 (as of June 2007. A copy can be found in the ICalenders doc/RFC folder - rfc4918-WebDAV Update.txt) section 7.3 writes "WebDAV provides the ability to send a LOCK request to an unmapped URL in order to reserve the name for use. This is a simple way to avoid the lost-update problem on the creation of a new resource (another way is to use If-None-Match header specified in Section 14.26 of [RFC2616]). It has the side benefit of locking the new resource immediately for use of the creator". To the best of my knowledge this indicate that the latest specification allows this - later on it even mentions "A successful lock request to an unmapped URL MUST result in the creation of a locked (non-collection) resource with empty content".
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.
I would think shared calendars is another strong candidate. Conflicts with shared calendars should be a concern for the server and not the client. IMHO.
BTW: such generic questions are better placed on the CalDAV mailing list: http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Sorry, I will immediately request to be listed:-) -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- Q: What do monsters eat? A: Things. Q: What do monsters drink? A: Coke. (Because Things go better with Coke.)
participants (3)
-
Cyrus Daboo
-
Helge Heß
-
Michael Rasmussen