Re: Proposal: WebDAV and transactions

I think it is clear that the best way to address this requirement is through
batching up WebDAV METHODS into a single request.  We also have requirements
for doing batch methods for other reasons, and I know Microsoft has also run
into this requirement and extended the standard this way.

--Eric

----- Original Message -----
From: "Babich, Alan" <ABabich@filenet.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>; "Pill, Juergen"
<Juergen.Pill@softwareag.com>; <w3c-dist-auth@w3.org>
Sent: Monday, September 09, 2002 12:36 PM
Subject: RE: Proposal: WebDAV and transactions


>
> The database vendors faced the issue of transactions in a client-server
> network when they distributed their databases some ago. The naïve approach
> of just remoting each database call was a performance disaster on large
> networks. That is why they invented database script programming languages
> and stored procedures. Stored procedures are scripts (in a database
> programming language) that allow fairly general database transactions to
be
> programmed. These scripts are stored in the database. Clients invoke the
> scripts by passing them parameters.
>
> Besides performance, one of the advantages of stored procedures is
> standardization of the database processing. The system doesn't have to
> depend upon every client getting the update processing correct. The stored
> procedures can theoretically enforce all the checking and standardization
> required. If one limits who can write stored procedures to a small trusted
> group, the integrity of the system is protected.
>
> As you pointed out, it is sometimes the case that the processing involved
in
> WebDAV transactions as you envision them is conditional on the result of
> previous processing steps.
>
> If you give people a gun they can shoot themselves in the foot with, then
a
> certain percentage of the people will shoot themselves in the foot. (I
know
> someone who literally did that.) If the gun refuses to shoot you in the
> foot, that is a better design for the gun. In the spirit of that analogy,
I
> am proposing that the entire transaction, conditional processing and all,
> should be invoked by one method call. That would do a lot to help protect
> the performance of the system.
>
> Within the single-method constraint, there are two ways to go: (1) Specify
> the entire transaction, conditional processing and all, within the stuff
you
> send over the network in the method invocation. (2) Invent stored WebDAV
> procedures that specify WebDAV transactions (conditional processing and
> all), and have the method pass parameters to the stored procedure. You
could
> think about taking either or both of these approaches.
>
> It is an open question as to whether either of the above two approaches
can
> be done well without doing violence to HTTP and/or WebDAV.
>
> Alan
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Monday, September 09, 2002 7:34 AM
> To: Pill, Juergen; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
> Jürgen,
>
> I think the main issue isn't that people aren't interested -- it's more
that
> they (well, I) think that it's an extremely bad idea that doesn't adher to
> the HTTP model.
>
> In particular, it would make the meaning of an HTTP method invocation
depend
> on previous method calls. That makes it hard or impossible for
> intermediaries to work with these messages.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen
> > Sent: Monday, September 09, 2002 4:17 PM
> > To: 'w3c-dist-auth@w3.org'
> > Subject: RE: Proposal: WebDAV and transactions
> >
> >
> >
> > Hello,
> >
> > I did not receive a lot of feed-back on the TA "proposal" (and the
> > statements were both positive and negative).
> >
> > Would you agree on the statement, the WebDAV group would be currently
not
> > interested in standardizing TA methods?
> >
> > As we would need this extension for the API implementation, our
> > option would
> > be to implement a proprietary WebDAV TA extension available on our
server
> > only.
> >
> > If the interest on this topic would raise again - possibly at a
> > later time -
> > we would be happy to share our experience with you.
> >
> > Best regards,
> >
> > Juergen Pill
> >
> >
> >
> >  -----Original Message-----
> > From: Pill, Juergen [mailto:Juergen.Pill@softwareag.com]
> > Sent: Monday, September 02, 2002 12.24 PM
> > To: 'w3c-dist-auth@w3.org'
> > Subject: Proposal: WebDAV and transactions
> >
> >
> > Hello,
> >
> > The current WebDAV specifications deal with a transactional support on a
> > method base only. Either a single WebDAV method is completely and
> > successfully executed, or the method is not executed at all (e.g. a
> > PropPatch command will either modify all requested properties or none of
> > them). A transactional support spanning multiple WebDAV methods
> > is currently
> > not specified.
> > Multi user requirements are either handled in separate workspaces
> > (Delta-V)
> > or via the Lock method.
> > During our discussion on the JSR 170 (Content Management API)
> > implementation
> > on top of WebDAV, we believe that we require longer transactions
spanning
> > multiple separate WebDAV methods. (This issue was already partially
> > discussed in the Batch method thread). Do you also fell the
> > need/requirement
> > to get a standard on the way, concerning a transactional WebDAV protocol
> > extension?
> >
> > A possible use case would be:
> > An author wants to modify an html page. To successfully do so, he will
PUT
> > the updated html page back, PROPPATCH and UNLOCK it, DELETE all bitmap
> > files, which are not references any more, and PUT (create) the newly
> > referenced bitmaps files. If he wants to ensure, that either all
> > his changes
> > do apply (or none of them) he would surround those method call with an
> > TA-BEGIN and a TA-COMMIT method call. If the author would be an API
(e.g.
> > JSR 170) exposing the TA functionality to an application, we believe
this
> > feature to be mandatory.
> >
> > A possible (starting) specification could be:
> > WebDAV defines 3 additional methods: TA-BEGIN, TA-COMMIT and TA-ABORT.
The
> > TA-BEGIN method will return a TA token (e.g. via an XML response
> > body). This
> > TA token will be send to the following WebDAV methods, which are part of
> > this transaction (e.g. via an additional header). The TA-COMMIT
> > or TA-ABORT
> > method will either commit or abort the transaction and invalidate the TA
> > token.
> > If and when an open TA, which is not used any more, is aborted, could be
> > controlled similar to the lock method timeout header.
> > All WebDAV methods, which either do not posses a TA token, or posses an
> > invalid token are handled as today (the method is executed within its
own
> > TA), this would ensure upward compatibility.
> > This extension would be optional, if a server supports the TA methods,
it
> > will state this in the OPTIONS request (similar to Delta-V).
> >
> >
> > Does this make sense?
> >
> > Best regards
> > Juergen Pill
> >
>
>

Received on Wednesday, 11 September 2002 02:02:28 UTC