Re: Distributed Authoring Proposals

>> That is true for the MIME recipient, but not for the MIME sender.
>> Unlike in MIME, WEBDAV represents the process of establishing on the
>> server the content of future sends, and therefore anything that
>> might be sent in the future must be acceptable as data and not
>> as control actions.
>
>Roy, is this true for PUT in general, or are you thinking that
>WEBDAV has some other special action? Is the PUT body in general
>required to be "this is what you will send as the content of
>future GET requests", or is it more complex than that?

Yes, this is true of PUT in general, and yes it is more complex than that.
The result of future GET requests will depend on things like authentication
and how the server interprets its url-space.

>For example, if we're storing a document with server-side includes,
>would you use PUT, or STORE-SOURCE, or PUT to a different URL?

PUT to a different URL (the URL of the source, which in most cases will
have different access controls than the URL of the derived resource).

>I wish I felt confident that WEBDAV actually had addressed these
>fundamental simple operations, before we went off onto long
>flights of design around COPY and MOVE and establishing metadata.

So would I.  The HTTP/1.1 spec is vague on these things precisely because
it needed to cover all possible implementations, and it was assumed that
the server would not allow a PUT on a non-PUTable URL.  The only thing
that people could agree on is what the user-agent means when it requests
a PUT, and how the server should respond for success/redirection/failure.

In HTTP, performing a set of related actions a la PUT of a
multipart/alternative is done by separate requests.  Creating a resource
that consists of multipart/alternative responses is done by PUTing
a multipart/alternative content.  We could define "special" types for
particular actions, but that hasn't been done before.  The only suggested
need for such grouped actions is to support transaction-style processing,
but there are far easier and more flexible ways of doing transactions
than with multipart media types.

.....Roy

Received on Friday, 28 March 1997 18:37:01 UTC