[OGo-Users] Linxu davfs and the open locally button

Werner Baumann users@opengroupware.org
Thu, 05 Oct 2006 21:38:51 +0200


Hello Helge,

I am the maintainer of davfs2, and I stronly disagree:

 > Its not a feature its an obvious bug. Since the displayname has no
 > requirement for being unique it cannot be used as a primary
 > identifier (like a filename in a filesystem).

There is no need to write down a requirement like this. For two 
different resources within the same container, you *must* present 
different names to the user, except you wont to wind up the user.

The WebDAV RFC clearly states:
Displayname "Provides a name for the resource that is suitable for 
presentation to a user." It is a *name*. If you need something else than 
a *name*, define a suitable property. WebDAV is open for this and I 
believe opengroupware allready makes use of it.

 > Well, and even if the user gets the displayname, how is he supposed
 > to continue in the file hierarchy if he doesn't know the name of the
 > file?

You obviously don't know, how davfs2 works. davfs2 uses a computer and 
it can therefore easily keep track of pathnames in uris and the 
associated displaynames.
So if a user types
less otto/heinrich
davfs2 will know that he wants the file bar in container foo on server 
opengroupware.org, and issue an GET /foo/bar.
Pleas have a look at davfs2. There is no need for theories about 
"backend infrastructures" to get this clear.

But the displayname was not the real problem for Sebastian. The real 
problem:
Pathnames for collection that are send by your server in the href 
element miss the trailing slash. The WebDAV RFC requires this trailing 
slash for collections. This missing trailing slash caused errors when 
davfs2 extractes the last component from the path.
davfs2 fixed this by checking for the slash and adding it if missing. 
But you should fix this too.

Greetings
Werner