Re: RE: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1  without required server extension ?

"Jim Whitehead" <ejw@cse.ucsc.edu> wrote:
>
> > WebDAV is ugly precisely because the HTTP and XML are 
> > horribly entangled. It's defined as a protocol, 
> > but the stack is not layered.
..
> 
> The simple fact is WebDAV defines a set of methods. These methods take
> parameters. Some parameters are encoded in headers, others in XML. People
> who have written DAV implementations don't have a problem with this.

There seems to be a level-mismatch involved in changing the transport layer in order to implement high-level services, especially when it's a
stateless transport layer with extremely stateful high-level functionality.

This leads to awkward practical problems, such as: having to change the
source code of the web server to let through new methods and status codes;
having to rewrite http client libraries in order to send the extra
headers and methods (e.g. java.net cannot be used for WebDAV).

And these are not one-off changes, since every time a new WebDAV extension
comes out, the methods, extra headers, and status codes all change.
Of course, the second rewrite is implemented as a configurable set of
properties, perhaps as it should have been from the start :)

Perhaps the biggest benefit of layering is it enables reuse,
i.e. other people are developing the other pieces: from standards,
through to implementations, products and open source projects. 
Less work should be a powerful motivation to achieve orthogonality.

> > It really implies a data model, yet that data model is not rigorously
> > defined.

> This is pretty typical of IETF standards, which are concerned with
> on-the-wire encoding, and are less interested in the underlying 
> data model. The result is an implied, but not normative data model. 

> The marshalling decisions are not the ones we spent most of our
> time on -- it was deciding things like "how does a locked hierarchy 
> interact with move" and "what are the semantics of move/copy on 
> live properties". These are tricky, subtle issues which require a lot of
> time to sort out.

I agree the model and semantics are harder than the transport,
but all the more pity that at the end of a long process of discussing the
real details of the model, you do not actually have a normative model in
black and white, to hand to someone who wants to model in UML, RDF or ER.
The work has been done, but the clarity is obscured by recasting the
answers as a protocol. It also makes the discussions, and the
final standard, very obtuse, because you get circumlocutions such as:

"method postcondition: the object (which we do not really have), 
has a state (of which we dare not speak its name) of a certain 
(but unspoken) type, and the final value of this pseudo-state on this pseudo-object, should probably be X (but we can't insist)."

Of course, XML has almost been broken trying to make the transition
from serialization format to model-centric system (infoset, schema, query).
I would argue this is more to do with the explosion of XML politics,
rather than any deep technial problems, but it's hard to be sure.
Perhaps the best summary of the clash of cultures between the 
pointy-bracket syntax-driven doc-heads and the curly-brace class-conscious
object-geeks, is Ron Bourret's witty "myths":

  http://www.xml.com/pub/a/2000/03/08/namespaces/index.html
  
> > In the history of computing, it has often been the case that a
> > general purpose solution, bound to a specific application domain,
> > has delivered a more versatile, powerful, and ultimately longer-lived
> > solution, than a bespoke specialized language or protocol.
> 
..
> I think it is incorrect to draw any technical lessons from
> the adoption of SOAP. What makes SOAP different from RPC/IIOP is that
> Microsoft and IBM both agree on this one. That is, it is the 
> non-technical issue of sponsorship of the standard that far 
> outweighs any technical properties of the solution. 

I agree that politics are more important than technical properties.
But there is another important pratical aspect, and that is the 
general 'developability' of the technology: is it flexible ? is it
easy to start developing solutions using standard tools ? does it
evolve smoothly to encompass new requirements ? does it compose
orthogonally with other layers and components ? etc.

> > SOAP-based web service architectures rely on a design-driven process
> > of data modelling/schemas, selecting an interface to publish,
> > followed by auto-generation of components for service discovery,
> > messaging, data (un)marshalling, method dispatching and invocation.
..
> > If WebDAV had a data model, it would be an almost trivial task to
> > create a web interface definition, auto-generate the communication
> > components and publish it as an web service !

There's another pathway which might be more appropriate, 
and that is to specify WebDAV methods as WSDL interfaces,
then use various class generators to spit out the comms components.
This has the merit of being a closer match to the protocol, does not
require a complete data model, is language independent, and should be
able to bind to most existing data model implementations (given a 
flexible enough WSDL mapper-compiler).

Here are a couple of references for (quick hack) DAV-ish web services:

  http://www.xmethods.net/xfs/
  http://www.soapware.org/xmlStorageSystem

And thanks for answering a newbie's frustrations !

Mikhail
__________________________________________________________________
Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/

Received on Tuesday, 29 May 2001 12:50:52 UTC