Re: Comments on the "new" 2518

Kevin wrote on 03/01/2006 08:42:59 PM:

> Section 15 makes ?Display Name? a customizable live property. 
> Putting on my SERVER hat, this seems easy (although not something 
> that Xythos allows today).  That being said, I am concerned about 
> what this really means in the client world.  The three most used 
> Webdav Clients (that I know of at least) attempt to make a webdav 
> server look and feel to the end user like a mounted file system.  We
> can argue that this is not a good idea, but in practice, this is 
> what has been implemented.  The question for a client developer is 
> ?what to show to the end user, the display name or the URL.?

That depends on what the end user is going to do with it.
If they are going to copy the string and paste it into their web browser,
then you'd better show them the URL.  If they are just going to look at
the string, then the display name is better.
 
> I 
> would argue that most end users would want to see the display name 
> (especially with servers that give names to resource URLs that are 
> not friendly). 

They are two different strings, with different properties, so in some
cases they want one, and in other cases, they want to other.

> Let?s look at some scenarios (assuming that the 
> client is a command line interface with display names being used as 
> the directory/file names):

In this scenario, they clearly want the URI (if "being used as the
directory/file names", you mean that they want to be able to use those
strings to locate the resources).

> n       /123/234/345.txt is a valid URL while the display names map 
> to /foo/bar/fee.txt

Concatenating the display names, separated by slashes, has no guarantee
of producing anything sensible.  The displaynames can contain slashes and
spaces and random other punctuation (and non-legal URL characters).

> n       /123/234/456.txt is also valid at /foo/bar/fuu.txt

I don't know what you mean by "is valid at".

> n       mv fee.txt lala.txt => proppatch (possibly giving the user 2
> filenames that are the same, which most operating systems don?t like)

You cannot use the concatenated displaynames as a filename.
If you want a pathname, the only sensible choice is to use the URI.

> If we do have display name as separate, can it be non-unique?

Yes.  There was never any guarantee of uniqueness.

> The 
> whole fact that there are two names for things (with different 
> rules) seems very confusing to end users. 

There are always many different names for things.  There are pathnames,
that allow you to locate an object, and there are descriptive names,
that do not allow you to locate an object, but do allow you to describe
the object in a less constrained way than a pathname segment.

> Of course a client could 
> ignore display name completely (or make a new column for it in a 
> directory listing detail) but that has lead to some usability issues
> for some end users as well.

If a client doesn't want to display the displayname, that is up to the
client.  There are many repositories for which a displayname is very
useful (especially those which have large flat collections, where the
resources in the collection have obscure last segments, such as UUIDs).

> (Note that ?some? of the MS webfolder 
> clients show display name although they issue MOVE?s to nonexistent 
> resources if you try to rename them).

Poorly written or buggy clients will always exist.

Cheers,
Geoff