Re: Collections that Support Naming/Numbering

Jim Davis wrote:
> 
> Reactions to Ellis Cohen's proposal (of 17 Dec 1997).
> 
> I am mostly in support of this.  It adds power at low cost, in a fully
> compatible way.  I have just a few questions/comments.
> 
> At 12:20 PM 12/17/97 PST, Ellis Cohen wrote:
> >==================================================
> >    Collections that Support Naming/Numbering
> >==================================================
> >...As an option, collections can support external references.
> >A collection that supports external resources must
> >support naming and/or numbering of collection resources.
> 
> We've already been over this point, so I'm merely repeating what I think is
> now agreed upon by all:  change the word "must" to "may".  (I'd be fine
> with "should" but doubt we could reach concensus on it.)

Yup; may is OK with me

> >In a collection that supports naming, all resources in the
> >collections have names.
> 
> Just to be clear, must the names be unique?

Yes

> If so, what status code is
> returned if one attempts to ADDREF or PUT with a name that already exists?

In ADDREF, if the Member-Name is the same as an existing name, then
I think the collection resource should be replaced (consistent with PUT)

PUT is only extended to support numbering, so I don't think it's an
issue

> Can an external resource be present twice, with two different names?

Yes

> 
> >  GETREF: Returns the resource given its name
> >     (in the Member-Name header).
> >     Could work for both internal and external
> >     resources.
> 
> Why do we need this, given that the semantics of GET are defined (below) to
> use the name?  That is, for collection 'http://foo.com/zippy' that has an
> external member http://quux.com/pinhead.html with name fish.html, GET
> http://foo.com/zippy/fish.html -> http://quux.com/pinhead.html
> 
> What is GETREF doing besides this?

GETREF on http://foo.com/zippy
with Member-Name: fish.html
just returns the text "http://quux.com/pinhead.html"
with status OK

GET http://foo.com/zippy/fish.html
returns a redirection response with Location:
http://quux.com/pinhead.html
 
> The link idea is cool, but it's not clear to me what are the intended
> semantics of the other methods (PROPFIND, PROPPATCH, LOCK) on external
> members when accessed via a link.  Ellis can you elaborate?

The semantics of the redirection, so if http://foo.com/zippy has an
external member http://quux.com/pincushion (itself a collection)
with name whoopee, then

PROPFIND http://foo.com/zippy/whoopee
returns a redirection response with Location: http://quux.com/pincushion
which should result in the new request
PROPFIND http://quux.com/pincushion

  -- Ellis

Received on Thursday, 8 January 1998 18:14:24 UTC