RE: Ideas: GETSRC & MULTIPUT

> Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property?
> (If it is just a shorthand for this, I'm against the redundant marshalling
> of this request through a new method).

The source link has not been implemented. We don't currently have two
interoperable implementations. Thus, according to IETF policy, the source
link goes away in the revision of 2518.

At that point, we have no mechanism for accessing the unprocessed source of
a link. Hence, no duplication of mechanism.

Being a pragmatist, the source link hasn't worked. To me, this suggests a
different approach. I like a new method better than the Translate header,
since we're really asking for a different aspect of the state of the
resource than a GET.

> As for MULTIPUT, that sounds fine to me, but it should be accompanied by
> a MULTIGET, which would allow reading of a resource and its metadata in
> one transaction.

I think the case for MULTIGET is much weaker. A client cannot easily
implement a PUT/PROPPATCH transaction with existing methods. If one of the
two methods fails, it's hard for the client to rollback. That is,
MULTIPUT/MPUT/PKG is not a network optimization -- it's accomplishing
something that is difficult, if not impossible, for a client to do right
now.

But, if a client does a LOCK (exclusive), GET, PROPFIND, it is guaranteed to
get the properties that are consistent with the body of the resource.

- Jim

Received on Monday, 29 October 2001 19:14:41 UTC