> From: Greg Stein [mailto:firstname.lastname@example.org]
> Sent: Sunday, January 05, 2003 3:45 AM
> To: Julian Reschke
> Cc: email@example.com
> Subject: Re: Adding a no-op LOCK to mod_dav_svn
> > As far as I understand, a lock table (whether persisted or not)
> would have
> > to record:
> > a) an identifier of the resource that's stable even when the
> name changes
> > b) the etag (or something equivalent)
> > c) a counter of locks issued for this resource
> > c) can be a single counter that is incremented for any lock
> that is issued.
> > a) and b) should be known anyway.
> I don't understand (a). Locks don't move with the resource, so the name
> would never change.
You need to avoid to have the same lock token for the same URI as well.
MOVE a -> b
The two lock tokens issued MUST be different. Of course if you have c)
implemented as global counter, this is guaranteed anyway.
> > Proposal:
> > 1) Upon server start/restart, obtain some fresh UUID.
> Hunh. I missed this optimization. It can only work if you use the
> "Extension" in the definition of the opaquelocktoken scheme. Neat.
Yes. It avoids unnecessary UUID generation, which can be expensive.
> > 2) Keep a counter of locks that were issued since the restart
> > 3) Build lock tokens of the form (see RFC2518, section 6.4):
> > "opaquelocktoken:" + uuid + "-" + "-" + counter "-" +
> nodeid + "-" + etag
> Anything following the uuid must be an RFC2616 "path".
OK, so some of the components may need escaping, depending on their syntax.
> > 4) Keep a list of all resources that were locked, and the lock
> token that
> > was issued (and ideally some owner information -- some clients
> will break if
> > the owner information they submit with the lock request isn't
> > 5) Do not support deep locks and/or shared locks.
> Yes, this would simplify things.
> Justin Erenkrantz has taken the locking code out of mod_dav_fs, simplified
> it, and checked it into Apache 2.1 as mod_dav_lock. It is basically a
> generic locking provider, and supports "everything" about locks
> shared, deep, record the owner, etc).
> It will be interesting to see how well it works with mod_dav_svn. Also,
> whether it can detect a "loss of lock" if the repository changes through
> something besides DAV (e.g. local access).
It may make sense to check the current implementation with the results of
the latest LOCK-related brainstorming on the WebDAV mailing list (note that
this is a simplified model that's compatible with RFC2518 and the new BIND
method, but doesn't mention the now-obsolete LOCK-NULL resources anymore):
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Jan 5 14:02:11 2003