Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Elliotte Rusty Harold on Web Services
 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, etc. 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 ABS -- A city is like a large, complex, rabbit - ARP 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
