RE: Advanced collections and ordering

At 09:57 4/12/99 -0400, Slein, Judith A wrote:
>The advanced collections design team has been discussing what to do about
>server-maintained orderings.  One thing we could say is that a collection
>with a server-maintained ordering is just an unordered collection as far as
>the protocol is concerned.  If the client doesn't specify an ordering, the
>server does whatever it wants, and if that happens to be alphabetizing by
>name, that's no different as far as the protocol is concerned than if the
>order is random.

>Or we could go a step beyond this and provide some way for the server to
>declare what its default ordering is -- to let the client know that it can
>count on responses to PROPFIND always listing collection members
>alphabetically by name.

...or sorted by collection vs. non-collection, by extension, ...

>Or (if there are real scenarios to support this) we could go further and
>allow clients to choose from a list of available server-maintained
>orderings.

>Do you know of applications that need this third kind of support, or servers
>that really offer clients a choice from among multiple server-maintained
>orderings?  Thanks for any help you can provide.

The standards that get set down here will actually affect the nature
of the applications.  Currently, PROPFIND returns unordered results,
so anyone writing clients that use PROPFIND are likely to add sorting.
If it becomes common to implement the ordering in the advanced 
collections protocol, then clients will tend to display the ordering
they get back from PROPFIND, and probably offer to sort it on the client 
side after you get a look at the default ordering.  When *that* becomes
common, there will be a demand for automatic ordering of PROPFIND
results, because people will want nicely sorted views on the information
coming back from PROPFIND on the first retrieval.

I'm not sure we need an immediate standard for how all server-maintained
orderings would work; a placeholder that would allow storage of a string
property would probably be enough.  (Over here at Glyphica, I've got a 
hack that makes it look like a URI:  /directory/extension.i/filename means 
"put directories first, then sort case-insensitive on extension, then sort 
case-sensitive on filename".)

I think Jim Davis is correct in that we don't want to take this so far
it becomes a stored DASL query.  If we want a standard for it, I would
suggest that only a limited list of properties be available for sorting--
perhaps:

	DAV:creationdate
	DAV:displayname
	DAV:getlastmodified
	DAV:getcontenttype
	DAV:getcontentlength
	DAV:resourcetype
	DAV:lockdiscovery

The sorting would not be necessarily ASCII sorting of the properties:
sorting on DAV:lockdiscovery would allow you to group all the checked-out
files in a directory into one location, for instance.

-- 
%% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %%
%% "Before enlightenment:  sharpen claws, catch mice.                   %%
%%  After enlightenment:  sharpen claws, catch mice."            - me   %%

Received on Monday, 12 April 1999 18:50:40 UTC