OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Elliotte Rusty Harold on Web Services

[ Lists Home | Date Index | Thread Index ]

On Monday 10 February 2003 01:32, Mark Baker wrote:
> On Sun, Feb 09, 2003 at 04:22:56PM -0800, Don Box wrote:
> > Seriously, it's naive for someone to think that their protocol will be
> > used in only the way they originally anticipate.
> HTTP is extraordinarily extensible, and therefore designed to be used in
> very unexpected ways.  That's not the problem.  The problem is when it's
> used in ways which obliterate all the desirable architectural properties
> that made it successful in the first place.

I'm concerned that people think it's normal for protocols, languages, and so 
on to be used for things they were never designed for.

Because it will only be by luck or by hacks that it will be as good as those 
tasks as things that were *designed* for them.

Not that I think we need a plethora of super-specialised protocols and 
languages that are fundamentally very similar, either!

Now, HTTP was designed for delivering HTML, and evolved to deliver 
multimedia. Architecturally it's a kind of pull-based email, really; the 
headers are taken right out of RFC2822.

Now, it's managed quite well at having non-human-oriented information such as 
Web service requests and responses plumbed over it, but things like SOAP have 
arisen, at least in part, to try to extend the areas where it is perceived to 
be weak; the SOAP people say they wanted more detailed and structured headers.

But why didn't TimBL start off designing HTTP as a general message-passing 
protocol in the first place? Probably because it would take too long to work 
out the details, and I doubt he was even aware of the issues involved in 
something like that. So he made something simple, and it later grew. But 
because he made certain initial assumptions, it grew in a less elegant way 
than it otherwise might have.

We have a plethora of protocols built on top of TCP that all have to handle 
certain basics underneath; authentication, delimiting the boundary of a 
request or a response, tying responses back to requests, dealing with errors, 

I see many arguments for using HTTP to do everything based on the fact that 
it's one of the most generic TCP protocols in the RFC series, so you can 
build stuff on top of it rather than having to write your own protocol for 
everything and reinventing all the basics.

The world is obviously desiring a protocol for application development that 
sits above the TCP/UDP layer; HTTP is being positioned for that because it's 
the nearest thing to hand.

But I'd far rather we just came up with a proper protocol and then based HTTP 
on top of *that* :-)

> MB


A city is like a large, complex, rabbit
 - ARP


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS