Subject: usage of href XML element

From: "James Woods" <[email-masked]>
Date: Thu, 16 Aug 2001 16:09:32 -0700

Hello all,

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

I have one issue that I am trying to clear up.
Okay, I am apologizing now if I don't explain this very well....

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?

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
My server would place this file in the database, generate the itemid,
but.... how do I get the proper URI back to the client?
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.

Thanks,

James Woods
[email-masked]