Re: Should I use displayname?

At 02:54 PM 1/22/00 -0500, Geoffrey Clemm wrote:
>I don't think anyone is assuming that the URL always refers to a
>filename.  The real question is under what circumstances the URL
>cannot be made meaningful to the user.  In a common authoring
>scenario, the author selects a collection, and then does a PUT, COPY,
>MOVE, MKCOL, MKRESOURCE, or whatever, to create a new member of that
>collection.  It doesn't matter whether the resource is implemented as
>a file, a database record, or whatever.

Geoff,

      My mistake.  As you picked up on, the key word I was referring to was 
"meaningful", not "filename".  What I should have asked is "isn't it risky 
to assume that the URL always represents something meaningful to the 
user?".  I would argue that the answer is Yes, in that the DAV server 
should be able to choose to use URLs that mean something to the internal 
representation of the objects but that are complete gibberish to the 
users.  Forcing the server to generate URLs that are meaningful to the user 
puts a severe limitation on server design, IMHO.

>What WebDAV protocol do you use to create a new update request?
>There currently is no "create a resource and assign it whatever name
>you want" request.  The versioning protocol has introduced a couple
>of methods like that to create specific versioning metadata resources,
>but normally resources contain the URL assigned to them by the user.

      WebSite Director is a workflow/approval-based authoring system.  When 
you send PUT, MOVE, COPY, or DELETE methods to WebSite Director, the change 
is not immediately made to the filesystem, which would defeat the purpose 
of an approval system.  Instead, WebSite Director automatically creates an 
update request in the workflow system that matches the original DAV 
request.  Following the necessary approvals of that update request, the 
actual update to the web site takes place.  It is functionally equivalent 
to an FTP "incoming" directory, where a system administrator has to take 
some action to make an uploaded document visible and available to users by 
moving it out of the "incoming" directory.

       Consequently, WebSite Director assigns each new update request an 
internal identifier, which is used in the URL to refer to that pending 
update request (there's no point in using the original URL provided by the 
user since the update hasn't been published yet).  That URL is in the form 
mentioned previously, "/WSD/Editing/requestB18894", for example.

>By ugly URL mangling, do you mean making the last segment of the URL
>be the displayname?  Why is this a problem (other than the
>internationalization issues that Jim mentioned, and perhaps concern
>about the length of the URL)?

      To be able to use Web Folders effectively with our workflow 
processing (since Web Folders doesn't do anything with the displayname 
property), we are adding functionality to mangle the URLs of update 
requests so that the above mentioned request would instead have a URL of:

/WSD/Editing/MOVE |mydir|myfile.html TO |otherdir|myfile.html

       To be able to handle DAV methods against the above object, WebSite 
Director has to convert that mangled URL back into the internal identifier 
to figure out what to do.  Just the simple fact that you can't include "/" 
characters in the "filename" component of a URL makes the above mangling 
very ugly.  We settled on the vertical bar ("|") character as the closest 
approximation that we can get away with, but it's still very ugly.  If, on 
the other hand, Web Folders (or any other DAV client) were to check for a 
displayname property, containing "MOVE /mydir/myfile.html TO 
/otherdir/myfile.html", for example, and display that to the user if it was 
found, it would work very smoothly for the client, the server, and the user.

Cheers......   Randall


Randall Severy    severy@cyberteams.com    http://www.cyberteams.com/severy
CyberTeams, Inc.    info@cyberteams.com    http://www.cyberteams.com
Mt. Airy, MD
(301) 829-6144          "Building effective teams in cyberspace"
1-888-832-5575

Received on Saturday, 22 January 2000 15:43:39 UTC