- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 17 Sep 2002 09:37:42 -0400
- To: Webdav WG <w3c-dist-auth@w3c.org>
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