RE: Proposal: WebDAV and transactions

Jürgen,

I think one should try to achieve the same goal while staying inside the
boundaries of HTTP.

For instance, one could define a specific "transaction resource", and use
POST to append specific method invocations to it. You might also want to
present your use case on the REST-discuss mailing list...

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:54 PM
> To: 'Julian Reschke'; Pill, Juergen; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> Hello Julian,
>
> I agree, TA adds a new aspect and quality to http (or WebDAV) and a new
> useful functionality, IMO. If it would go beyond the scope or
> philosophy of
> Http (or webdav) there is no need to get a standard on the way.
>
> The only issue I could see, is - if many people feel the requirement for
> this functionality too - that we get a series of WebDAV TA
> implementations,
> which are not interoperable any more.
>
> Best regards,
>
> Juergen
>
>
>
>
>  -----Original Message-----
> From: 	Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent:	Monday, September 09, 2002 16.34 PM
> 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 Monday, 9 September 2002 11:06:00 UTC