Subject: Comments on the "new" 2518

From: "Kevin Wiggen" <[email-masked]>
Date: Wed, 1 Mar 2006 17:42:59 -0800

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."  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).  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):

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

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

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

*       mv fee.txt ../fee.txt => move (it is possible this would fail
because a different 345.txt already exists in 123, this would be very
confusing to the user as they would have no clue WHY there move is
failing)

*       mv fee.txt ../lala.txt => move + proppatch (notice there is no
way in Webdav to do this as a single transaction, it is possible this
command could leave the user in a messed up state)

If we do have display name as separate, can it be non-unique?  The whole
fact that there are two names for things (with different rules) seems
very confusing to end users.  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.  (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).

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 1 Mar 2006 22:53:26 -0500

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Mar 2006 09:19:28 +0100

Kevin Wiggen wrote:
>  
> 
> Section 15 makes “Display Name” a customizable live property. Putting on 

...clarifies. As far as I can tell, this has always been the intent. 
Implementing it as a protected property that always has the same value 
as the last path segment (after un-escaping), such as in IIS, simply is 
completely useless for clients (because it just mirrors information that 
is already there).

> question for a client developer is “what to show to the end user, the 
> display name or the URL.”  I would argue that most end users would want 

The URL.

> resource URLs that are not friendly).  Let’s look at some scenarios 
> n       /123/234/345.txt is a valid URL while the display names map to 
> /foo/bar/fee.txt
> 
> filenames that are the same, which most operating systems don’t like)
> 
> n       mv fee.txt ../fee.txt => move (it is possible this would fail 
> confusing to the user as they would have no clue WHY there move is failing)
> 
> n       mv fee.txt ../lala.txt => move + proppatch (notice there is no 

Yes. It's a description, not an identifier.

BTW: lots of servers have been implementing it this way for years, so 
this shouldn't come as a surprise to clients...

> well.  (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).

Which has been reported as a bug and indeed been fixed. As a matter of 
fact, I think this is the only case where I've been able to convince 
Microsoft in immediately fixing something in the client :-). See 
<http://greenbytes.de/tech/webdav/webfolder-client-list.html#issue-displayname-1> 
and 
<http://greenbytes.de/tech/webdav/webfolder-client-list.html#issue-displayname-2>.

Best regards, Julian