Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

>
> 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