[
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,
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
|
