RE: collection with ordered members

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.

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.

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.

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.

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

			Yaron

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	Tuesday, October 28, 1997 11:56 AM
> To:	Yaron Goland; 'Judith Slein'
> Cc:	w3c-dist-auth@w3.org; Jim Whitehead (E-mail)
> Subject:	RE: collection with ordered members 
> 
> At 10:20 AM 10/28/97 PDT, Yaron Goland wrote:
> >Ahh.. you are not arguing for a new feature, you are arguing for a
> >performance enhancement. 
> 
> Actually, I think the argument is for a new feature, not merely a
> performance enhancement.  The new feature is a means of defining the order
> of elements returned by an INDEX.
> 
> Judy was refuting your previous claim ("no magic bullet")  that servers
> would have to understand compount document (internal) formats (and that
> clients would have to do discovery) by showing that the burden of
> understanding would remain with the client.  In this case, the client who
> wishes to store a compound document with (ordered) parts A B and C does so
> by arranging to do the PUTs of A B and C in the desired order, and the
> server promises that calls to INDEX will return A B and C in that order.
> 
> That's about all that's needed, a promise to maintain order.  You'd also
> want to add one or two additional headers to HTTP so that one could do a
> PUT (or ADDREF) and specify the position of the new member relative to an
> existing one, or relative to the first or last.  And that's it.  For these
> small extensions, one extends the power of DAV a great deal.
> 
> I know for a fact that the applications I am writing need this, and that I
> am having to add kludges to accomplish it.  I tell you trul adding ordered
> collections would definitely make DAV substantially easier to use for many
> of the document applications I would be likely to write.  And hey, don't I
> work for The Document Company?
>

Received on Tuesday, 28 October 1997 17:34:27 UTC