Re: Issue #2 Definition of the term Referential Resource

At 10:36 PM 2/21/99 PST, Yaron Goland wrote:
>
>(Issue #2) Section 2- Definition of the term Referential Resource - It
>should be explicitly pointed out that this is a new resource type. I think
>this would make the definition clearer.

Good idea

>	The term "body" as used in RFC 2068 and 2518 refer exclusively to
>messages, not resources. Hence the phrase "body of its own" does not have a
>definition in either spec.

I agree.

> First off, I think
>we need to cease viewing direct references and redirect references as
>children of the same mother. They are two very different creatures with
>largely unrelated functionality. It would probably be in everyone's interest
>if they were given names which shared no common words.

I am afraid I don't agree, and you are wrong to assume that our inspiration
comes from file system links.  Indeed, I was more inspired by the ability
of some Web servers to define aliases by means of suitable statements in
their configuration files.  The purpose of MKREF is to allow ordinary web
clients to cause such behavior without having to be superuser on the web
server.

From the standpoint of a human using a web client, there's no important
difference in behavior between
 GET foo.html
 GET direct-to-foo.html
 GET redirect-to-foo.html

In all three cases, the human ends up seeing the contents of the resource
foo.html  (in the third case, the client app processes the 302 automatically).

We have direct references because that's (I claim) what most applications
want. We have redirect references because in the most general case,
implementing direct references is either expensive or opens security problems.

these are differences in the mechanism by which the desired end is
achieved, not differences in the ends.  We should follow good CS practice,
and identify these abstractions by their intended purpose, not the
mechanism by which such purpose is realized.

[PS thanks for all the thoughtful comments.  I have thus far only answered
the easy ones.  more on Monday.]

Received on Friday, 26 February 1999 13:38:54 UTC