RE: BIND vs. non-movable resources in RFC3253

Perhaps what's lying at the core of this issue is a difference in assumption
over who controls the namespace. The binding specification assumes that in
WebDAV-compliant portions of the namespace, the client has a large degree of
control over naming and deletion. Resources are created at locations the
client specifies, can be moved to places the client wants, and rebound to
new names at will.

The non-movable resources in DeltaV are typically created by the server, at
names the server chooses. Often these resources won't be represented the
same way as "file-like" resources, and will instead be acting as the handle
for a computational process that queries the versioned repository to return
property data. That is, they act more like a servlet or a CGI. In this case,
it's important for the server to have these resources at the place where it
created them, since that's where its software expects queries against those
resources to be directed. (It's additionally important that they stay in the
same place for the indentification usability issues Geoff outlined).

IMO, accommodating this difference requires explicitly acknowledging the two
different classes of resource binding behavior (fixed vs. free) and then
explicitly adding language describing the behavior of fixed types to the
binding specification (something similar to Stephan's language would
probably work). Revisions to DeltaV can indicate, for all DeltaV resource
types, what kind of binding behavior they exhibit.

As for why we should add this language -- the idea is to make it so that a
client, when encountering resources of both types, can behave intelligently,
without having to perform trial and error to accomplish useful tasks.

- Jim

Received on Monday, 21 October 2002 16:28:19 UTC