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

Can't resist...

> WebDAV is ugly precisely because the HTTP and XML are horribly entangled.
> It's defined as a protocol, but the stack is not layered.

You could make the same claim about HTTP, that it horribly entangles RFC-822
headers in with the request line of the message, without any firm layering.

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.

> It really implies a data model, yet that data model is not rigourously
> 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, bot not normative data model. Thus, for example,
even though DAV implies a data model of a resource payload plus properties,
it is possible to implement this is a number of ways (Unix files + property
database, NT filesystem files, database tables, as objects only comprised of
attributes where a single distinguished attribute holds the payload).

> SOAP evolved from XML-RPC, which was largely invented to perform site
> and content management at Userland, so the original domain and
> requirements are similar to WebDAV.

You're confusing a marshalling and basic transport mechanism (SOAP/XML-RPC)
with a semantic-rich protocol. XML-RPC and SOAP have almost no semantics
whatsoever.  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 in a
consensus-driven standards group that is open to input from all comers, and
uses a transparent process.

For example, I'll note that people in W3C working groups feel no compulsion
to answer random questions from newbies questioning 4 year old design
decisions. Think about it.

> In much less than those 5 years, SOAP has evolved
> from XML-RPC, been adopted by major corporations (Microsoft, IBM, etc.),
> is reasonaly standardized and on its way through the W3C,
> become the basis of all web services architectures,
> acquired a complete layered stack (including WSDL and UDDI),
> and is likely to be the basis of all future web-delivered functionality !

Actually, I would trace the beginning of SOAP to the failed HTTP-NG effort
at the W3C, which was another attempt to define a "service-oriented"
infrastructure for the Web. It is no cooincidence that Henrik Nielsen was
heavy involved in HTTP-NG, then went to Microsoft, and became very heavily
involved in SOAP definition.

Furthermore, SOAP is not nearly as far along as WebDAV in terms of adoption.
Right now, people are using WebDAV in real-world settings to get their work
done. There has not yet been widespread adoption of SOAP. I have no doubt
that, given the marketing push by Microsoft and IBM, this will happen. But,
it's not there yet, and it will take some time yet before SOAP is at the
same level of standardization and adoption as WebDAV.

> 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.

So this is why Internet-based services took off using infrastructures such
as RPC, ILU, and IIOP, which were also language independent marshalling
formats, right? 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. Yes, the use of HTTP POST and XML for
marshalling undoubtedly helped Microsoft and IBM agree to use SOAP,
especially given the mindshare of XML in the 1999-2000 timeframe (I'll note
that the same SOAP proposal would have flopped in, say 1995-96, when XML was
still tainted by the stigma of SGML).

> 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.

Except for service discovery, this is *exactly* what you did using CORBA and
RPC.  You created a data model, described interfaces, compiled those
interfaces into marshalling and unmarshalling stubs, with method dispatching
handled automatically.  So, why didn't these frameworks take off for
Internet use? Claiming that they don't go through firewalls is a red
herring -- if a company wants to host a service, or use a service, and have
a strong business need to do so, they'll make sure packets can get through.

> 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 !

Again, the marshalling issues were not the heart of the complexity of the
WebDAV protocol, and are not the heart of the complexity of WebDAV
implementations.

> Who can doubt that if WebDAV was starting today,
> it would be defined as a SOAP-based service ?

Me. I'm going to be very glad that, when administrators tell their firewalls
to not admit POST (so someone in the company doesn't set up a rogue Web
service and introduce a security hole), WebDAV will not be affected.

- Jim

Received on Friday, 25 May 2001 17:25:32 UTC