- From: Randall Severy <severy@cyberteams.com>
- Date: Sat, 22 Jan 2000 15:40:53 -0500
- To: w3c-dist-auth@w3.org
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