- From: Ilya Kirnos <ilya.kirnos@oracle.com>
- Date: Wed, 01 Aug 2001 19:52:59 -0700
- To: "Hall, Shaun" <Shaun.Hall@GBR.XEROX.COM>
- CC: w3c-dist-auth@w3.org
> > I don't think LNRs should be changed at all. > > You could use a file to track the lock if you wish and you won't be > deviating from the RFC. > > The RFC doesn't place restrictions on implementation (in this case LNRs) - > you can basically use whatever you want, so why are you suggesting that the > semantics should be changed ? > > Its an implementation problem, not a protocol problem. > As I recall, there are some restrictions on the behavior of a lock-null resource that make it difficult to track with an honest-to-goodness file. For example: As I recall an LNR is supposed to show up as a member of its parent collection, but return 404 when you try to do a GET on it. This means you have to keep some metadata about that file to know that it's 'special'. You can keep it in the DAV server, but nobody else would know or care about it, so even another DAV server (forget other protocols) working against the same filesystem wouldn't know about the 'specialness'. Why would you want to limit DAV locking in this way if you have a filesystem that supports locking natively, for example? I think there were other examples as well. Generally, IMHO, LNRs have unusual behavior, and perhaps we can solve the problems LNRs are intended to solve and make them a little easier to implement on many existing systems. Like I said, I'd be up for keeping LNRs if things like this were amended. I know these are all implementation details, but if the implementation becomes one hack after another, as I think LNRs would have to be as currently defined, maybe it's time to step back and revisit the spec. -ilya
Received on Wednesday, 1 August 2001 22:52:09 UTC