Al Brown wrote:
> Julian,
>
> I saw a post on the JSR list and it prodded to me to (re)read the
> appropriate rfcs. If you look at copy
> (http://tools.ietf.org/html/rfc2518#section-8.8) or move
> (http://tools.ietf.org/html/rfc2518#section-8.9), it is articulated to
> copy (or move) a resource from location a (uri1) to location b (uri2).
The relevant RFC nowadays is RFC 4918, but, yes, that is correct.
> These locations are fully specified to be where the object will live
> after the verb. They include the location under the folder, rather than
> uri2 being the uri to the folder. Am I understanding COPY and MOVE
> correctly in WebDAV?
>
> This is a discrepancy with the CMIS model.
>
> In CMIS, we have:
> - moveObject (object, folder)
> - addObjectToFolder(object, folder)
> - removeObjectFromFolder(object, folder)
>
> In WebDAV case COPY/MOVE would want uri2 to contain the location of the
> object in the folder: e.g. http://foo/folder1/newlocation where in CMIS
> it should be http://foo/folder1.
I keep forgetting that :-).
Is the assumption that the server will assign the collection-local name?
> In CMIS, there is not a notion of path, only folder containment. All
> URI's in the rest binding are basically repository-specific how they are
> generated. The most a client can do is specify the Slug ala app.
>
> If we would like to use COPY and MOVE, wouldn't we have to redefine COPY
> and MOVE for CMIS?
If there's no way for the client to "guess" the final URI (like "new
folder name / old local name" -- which I doubt), then yes, MOVE and COPY
wouldn't work as desired.
If we wanted to use COPY/MOVE, we'd need an extension (such as
"Destination-Collection" instead of "Destination"). On the other hand,
we could standardize the "Allow-Rename" header
(<http://msdn.microsoft.com/en-us/library/aa142703(EXCHG.65).aspx>),
which apparently is already supported in some Microsoft products.
BR, Julian
