[OGo-Developer] FYI: linux davfs2 access to ogo projects

[Helge Hess]

On Oct 6, 2006, at 07:58, Sebastian Reitenbach wrote:
> I tried to get the linux davfs2 working with ogo, did a lot of  
> testing and bug
> reporting. these bugs i stumbled across until now are fixed in cvs  
> by the
> davfs developer.

Great, nice guy! ;-)

> don't know whether you are interested, but one problem was that ogo  
> omits
> trailing slashes for directory names. citing the davfs developer:
>
> In HTTP/WebDAV it is a convention, that pathnames for
> directories have a trailing slash, while pathnames for files
> do not. But this is only a convention and there are
> different opinions whether it is a requirement. The WebDAV
> RFC requires it. davfs2 relied on this convention.

I think he is right wrt the trailing slash. Probably can be  
considered a bug in ZideStore.

> well, he fixed the problem, but maybe other webdav clients may face  
> the same
> problem.

Unlikely since it doesn't really matter in practice because URL  
processing is usually done by a regular, non-WebDAV specific URL object.
Not sure why davfs relied on this, probably some optimization.


> he also fixed the problem with how the <displayname> property is  
> used in ogo,
> that I mentioned in the users@ list. now there is an option to  
> disable its
> use. he disagrees with Helge on how <displayname> should be used:
>
> citing him:
> - WebDAV states that displayname "Provides a name for the
> resource that is suitable for presentation to a user".
> Except someone likes to confuse the user, this name must be
> unique wihtin a container or directory.

Its intentionally left up to the user. There is no "must be" in the  
RFC and I think there are few filesystem clients which use the  
displayname as anything but an _additional_ information.
Eg Windows WebFolders displays the displayname as the primary label  
but also shows the URL.

> There is no need to write this in any specification, it is obvious.

It isn't obvious. WebDAV is a protocol which can be used for arbitary  
"WebDAV collections", its not restricted to filesystems. Nor to  
filesystem browsers or servers. It can be arbitary clients (as  
demonstrated by GroupDAV which is a subset of WebDAV).

Displayname was propably invented for / is useful with database  
driven systems. Eg consider an address database like OGo's. While the  
unique ID of the HTTP leaf resources is say '12345' and '67890', the  
displayname would be just 'Donald, Duck' and 'Donald, Duck'.
Making the displayname unique wouldn't help the enduser with  
distinguishing the contacts at all, he must retrieve further  
properties to do that. Eg with calendar items the user usually does  
this by looking at time related properties. In a WebDAV client like  
Outlook/ZideLook he usually would configure the contactlist to show  
the city property in addition to the name of the record.

In fact Outlook has a 1:1 mapping for the WebDAV concepts (and M$ was  
part of the group which did WebDAV initially and Exchange was one of  
the first implementations, AFAIK). Eg an Outlook contact has a unique  
record id as well as a 'file as' property which is the displayname  
selected by the user.

> The real problem is: Some people will not treat it as a *name* but
> misuse it for some arbitrary, application specific data.

I don't think that this is the case. Is just a user presentable name  
which the user can either choose or which the server provides.  
Obviously names don't need to be unique, easy to prove ;-)

> They should define their own properties. WebDAV is open for
> this.

Yes, for arbitary data thats correct :-)

But eg in OGo projects the 'title' of a document is exactly that, a  
nice, user-defined name of the document the user has choosen :-)


Anyway, I agree that displayname for filesystems is usually something  
you don't want to have because you can and will get duplicates. But  
as mentioned its a bit shortsighted to view WebDAV just in the  
context of files, its arbitary web resources, be it an order record  
in the SAP database or some groupware contact.

Greets,
   Helge
-- 
Helge Hess
http://docs.opengroupware.org/Members/helge/