RE: Issue: Requiring server to use / terminated URL for returned coll ections

By "repository", I did not mean "file system".  In particular, we
store our information in relational tables, and we do not imbed in
the database keys information about whether or not the key is to
a "collection" object or a "non-collection" object.  

And as to whether this would "improve the internal representation",
storing redundant information on a reference is not an "improvement",
it is a costly change that needs compelling motivation.  So perhaps
we should focus on the "compelling motivation" before spending too
much time on "how costly" it would be for a server.

Cheers,
Geoff

 
-----Original Message-----
From: Roy T. Fielding [mailto:fielding@apache.org]
Sent: Monday, September 16, 2002 8:49 PM
To: Clemm, Geoff
Cc: Webdav WG
Subject: Re: Issue: Requiring server to use / terminated URL for
returned coll ections


> I strongly object to adding a MUST for servers returning slash
> terminated URLs for collections.
>
> Most repositories do not allow trailing segment-separator characters
> in the segment name of a resource, and therefore these trailing
> segment-separator characters are commonly just stripped off before
> that segment name is stored in the repository.  This means that in
> order to decide whether to add the segement-separator character back
> on, the implementation must query the repository for the type of each
> resource identified by that segment.  Forcing this cost on the server
> is only justified if it provides some compelling benefit to the
> client.

That's simply not true.  Most repositories store the type of a resource
along with the resource name in the collection (a.k.a. directory) and
thus that information is available at the time the segment is used
within a link describing the collection at no extra cost to the server.

All other repositories are fully capable of improving their internal
implementation.  OTOH, the protocol specification is responsible for
specifying that which is clearly most efficient for the protocol and
for those servers that have already anticipated its implementation.

....Roy

Received on Tuesday, 17 September 2002 10:08:24 UTC