Re: collection with ordered members

Yaron Goland wrote:
> 
> The promise to maintain order is a serious burden to implementers. Most DAV
> servers will most likely be implemented on top of file systems, current file
> systems do not maintain order so in to return the INDEX results in the
> promised order the server has to read in the entire directory, keeping it in
> local memory, sort according to the requested order, and then return it.
> However, without having to worry about order the server can stream the
> response as it reads it, never having to keep more memory around then what
> is needed for a single entry.

This is not how I would do it. It's up to the server implementer how they want
maintain the order of the resources that are implemented on top of a file
system, or where ever. 

Your argument (in a later email) that servers implemented on top of file systems
will have to deal with the problem of people dumping files in the "collection
directory" does not hold with me. If a server supports this kind of functionality
it needs to restrict access to repository. This problem exists on any server that
offers advanced features, for example maintaining link integrity, etc. A full
featured server might provide tools to import files into the collection but it
should not be necessary for the protocol to worry about these problems.

> 
> That is too much work and too much of a performance hit for a feature that
> no one has ever found compelling enough to even bother implementing.
> Remember, standards follow they do not lead. Given that this feature is no
> widely implemented it is clearly experimental in nature and should be
> explored using the experimental RFC mechanism, not thrown in to DAV where it
> will cause implementers endless headaches.

Ordered collections are something that will be widely used. We are already
using them to keep track of the order that sets of changes are applied to a
server. If you think about it a version history is an ordered collection.

> 
> Furthermore, I would argue that the feature is actually completely
> non-compelling since it breaks older clients. An older client may fully
> understand the compound document format being used but because it was
> written before DAV it would not be able to put the pieces back together.
> Whereas if it could simply do a GET on the resource and get back the entire
> document, then both DAV and non-DAV HTTP aware clients can interact with
> compound documents. Of course, that requires the server to be aware of the
> particular compound document format in use which reduces the situation to
> the case I mentioned before, which requires discovery for the particular
> formats the server supports, thus arguing for putting this feature in as an
> extension and not as part of the base DAV spec.
> 

I doubt that older clients are a factor when creating webdav enabled applications.
The spec is already so full of functionality that no one in their right mind
is going to implement a webdav enabled application that could possibly be useful
under a non DAV enabled client.

> Finally, the burden of proof for those arguing for this feature is not just
> to present a case for why this feature is needed at all but also to
> demonstrate why this feature is so compelling that we should force all DAV
> implementers to significantly damage their performance by implementing it.

I think that the arguments for compound documents are doing this. Version histories
are another feature where ordered collections are needed, especially if branching
is supported. Sets of change deltas that need to be applied against a file are
another. 

> In my opinion this is an experimental, extension feature and should be
> explored as such.
> 

As someone pointed out the changes required in the protocol are not that large, and
the pay back in flexibility would definitely be worth it.

Steve
-- 
                                     __
Stephen Martin         _   _   |    /_ \ MORTICE KERN SYSTEMS INC.
smartin@mks.com      ,/ \ / \  | / |(  |  185 Columbia Street West
(519)883-3215        |   |   | |/  | \ /   Waterloo, Ontario
Fax: (519)884-8861   |   |   | | \ | _)     Canada   N2L 5Z5
                                    \__/

Received on Wednesday, 26 November 1997 15:36:47 UTC