Re: Bodies of redirect reference resources

   From: Joe Orton <joe@orton.demon.co.uk>

   To me, the "reference resource" should be a resource in its own right: a
   conceptual thingy which say "No, go to URI Y instead", when you apply HTTP
   methods to it.

I agree.

   If you are trying to store an entity-body at URI X along
   with this RR, then that is two separate resources, one which has the "No,
   go to URI Y instead" semantics, and one which has the standard "I can
   store an entity-body with PUT and give it back with GET" semantics.

The presence of properties makes this a bit more ambiguous.  If you try
to get the properties of X, it will say "no, go to URI Y instead".  But
the RR X does have properties of its own, that you can obtain with the
Apply-To-RR header.  By analogy, it would be reasonable for X to have
an entity-body that you can obtain with the Apply-To-RR header. 
This doesn't convince me that RR resources should have entity-bodies,
but it is argument that it is reasonable to do so.

   Unix symlinks have precedent again here: you can't store a file in a
   symlink. Windows shortcuts are the same, I expect.

Yes.  I think this is a good argument against giving them a body ...
people will find this confusing, and experience in other domains indicate
that an entity body is not needed or appropriate for references.

   >    Is there a need to store an extra resource along with every RR
   >    resource?
   > 
   > The extra resource is minimally needed to store the information about
   > what other resource to redirect to. 

   What "information about the other resource" do you want to store? Why
   can't you store it in the properties of the RR? To me the only vital
   information you want to store in the RR is the target of the reference,
   which you have as the DAV:reftarget property.

I misunderstood you the first time.  By "extra resource", I meant the
RR resource itself.  You were talking about an extra resource *in addition*
to the RR resource.  I agree that there is no need for an extra resource
beyond the RR resource.  But the RR resource could have an entity body,
in addition to its properties.

   > We could do any of:
   > - get rid of the "an RR resource can have a body" statement
   > - get rid of this statement and change the example to say
   >   the PUT MUST fail.
   > - keep the statement, and change the example to say the PUT
   >   updates the body  of the RR resource.

   > That's one vote for choice #3.  Anyone else?

   Either you misunderstood, or miscounted :)

Neither ... mistyped (:-).

   I vote #2: get rid of any mention of "resource body",
   and have PUT + GET fail with 4xx if the Apply-To-RR header is included.

So we've got a vote for *2*.  Anyone else?

Cheers,
Geoff

Received on Sunday, 30 January 2000 23:45:10 UTC