RE: usage of href XML element

   From: James Woods [mailto:woodsja@us.ibm.com]

   I am working on a implementaion of a webdav server.
   The server is going to use a  database for the repository.

   In the database, all the resources use a unique itemid instead of the
   original resource name.
   So for example a
	GET www.server.com/file1.txt
   will have to go through a name resolver so that the database request is
   used with the itemid.
   and a
	PUT www.server.com/file1.txt
   will place this file in the database, generating a unique itemid.

   This is all fine, and I had planned to just create this name resolver to
   handle all of this, but then I was looking at the href element.

   I want to use the itemid as the URI for the item, and the displayname dav
   property to have the client show the resource name.
   For example, say I do a propfind on the root collection with depth 1
	PROPFIND www.server.com
   in the properties for one of the internal members
	<D:href> http://www.server.com/itemid1 </D:href>
	<D:displayname>file1.txt</D:displayname>

   Now the client uses the display name to display the file in the
"explorer"
   view, but has the href to the actual URI for requests (GET, LOCK, etc.)

   This is how I think these to elements were meant to be used (or at least
   how they could be used). Am I correct in this, or way off base?

Everything is OK up to here.

   If I am correct about how these two elements can be used, then my next
   problem is with PUT and MCKOL.
   For example
	PUT www.server.com/file2.txt

The argument to PUT (or MKCOL or GET or any other HTTP method) will
always be a URL, not the displayname.  So you would have to do the
PUT to a URL with the itemid, which is a problem if you want the
server to generate the dbid, rather than the client.

   My server would place this file in the database, generate the itemid,
   but.... how do I get the proper URI back to the client?

You can't.  PUT is required to take a URL, and required to create
a resource at the specified URL, not some resource at some other
server generated URL.

   The 201 status returned wouldn't allow me to show the client that the
   proper URI to request this file is actually www.server.com/itemid2
   The only way the client would be able to get the proper URI for this
   resource is to do a propfind depth 1 on the parent collection, and this
   does not appear to be the case for most of the clients I have tested.

   I think I know how this will turn out, but I was just wondering.

This is probably how you thought it would turn out.  If you want to have
the server generated itemid's, you are better off using the "displayname"
as the URL, and if you want to expose the itemid, expose it as a server
defined live property value.

Cheers,
Geoff

Received on Thursday, 16 August 2001 21:26:05 UTC