Re: Bindings and Other Methods (Section 10)

<johns>
> e would like to say the simple, straightforward thing:  That for any of
> these methods, the results of applying the method through one binding are
> identical to the results of applying the same method with the same headers
> and body through another bindings to the same resource.
>
> What prevents us from saying this are executable resources, which generate
> responses dynamically and may be sensitive to which Request-URI is used to
> access them.  If we try to take these executable resources into account, we
> are reduced to saying things that are so open-ended that they place no
> enforceable constraints on the behavior of GET, PUT, etc., when applied
> through different bindings to the same resource.

Why exactly is this a problem? Me, I'd consider it a feature; if I write code
that's sensitive to the Request-URI, it's probably for a good reason.  I may
want to be able to write a script once and place bindings to it in different
places that behave differently according to their location.  In fact, I *have*
written such a script.  On my personal site, I don't have access to the logs,
so I've placed index.cgi scripts in various directories that I want to monitor;
they log the hit and return a 302 to redirect to Index.html.  Since I didn't
want to maintain N copies of the script, most of them are symlinks.  Since the
302 requires an absolute URI, the script looks at the Request-URI to figure out
where to redirect to.
</john>

John, I don't think there's anything wrong with that.

Judith, I also think your wording is a reasonable attempt to define an
*enforceable* "same resource" without tying yourself in knots or use
recursive definitions.

I suspect we all have the same model of how we'd like bindings to work.

Question: Do we need any **enforcable** constraints?  Or do we just need to
express the model that is to be followed?  Or is what we need somewhere
in between? -- Anyway, what type of enforcability do we ***need***?  What
properties *MUST* not change depending on the binding operations?  What
*SHOULD* not change?

My thinking is that if the folks before us couldn't give us enforcable
definition of resource... then we're going to have difficulty defining
an enforcable defintion of "same resource".  Therefore we can talk
about "same resource", but we shouldn't really try to *strictly* define
it.

The main issue I see with not defining it strictly is that cach'ing
might be a problem with some resources.  But that's always the case.
Some resources or properties always be changing regardless of
bindings... so making a restriction for bindings is probably not the
right solution.  That being the case, we later can come up with a
cach'abilty extension to webdav if we all feel it's needed.

Judith?....

Received on Wednesday, 15 September 1999 18:32:16 UTC