- From: Jim Davis <jdavis@parc.xerox.com>
- Date: Tue, 28 Oct 1997 11:56:14 PST
- To: Yaron Goland <yarong@microsoft.com>, "'Judith Slein'" <slein@wrc.xerox.com>
- Cc: w3c-dist-auth@w3.org, "Jim Whitehead (E-mail)" <ejw@ics.uci.edu>
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 16:55:40 UTC