[
Lists Home |
Date Index |
Thread Index
]
Miles Sabin wrote:
>
>...
>
> I wouldn't. But it's one thing to say that HTTP, along with lots of
> supporting infrastructure, can do all sorts of interesting stuff,
> quite another to say that HTTP was designed for them or that it's
> optimal or even adequate.
What do you mean by infrastructure? If we spend a billion dollars on new
SOAP infrastructure or a half a billion dollars making software that
takes advantage of the full generality of HTTP, which is better?
>...
> Disconnected operation (whether deliberate or accidental) and
> endpoint mobility are the tricky cases. It can be done, but it's not
> pretty.
What's ugly about it? You set up a micro server on the client and POST
or PUT responses to it.
> ... Other protocols (or hybrids, HTTP+SMTP to name only the most
> obvious example) do a better job.
How so? Be concrete.
> > Consider what might be possible with vanilla HTTP 1.1 and;
> > - a web server near the user (such as in the browser, ala KnowNow)
> > - intermediaries adding value with queueing, caching, filtering,
> > routing, etc..
>
> All sorts of things certainly. But I don't see how you get from there
> to any kind of interesting or useful generality claim for HTTP. HTTP
> can be layered on top of SMTP, and IP can be layered on top of fleets
> of carrier pigeons: does that mean that SMTP is more fundamental than
> HTTP or pigeons more fundamental that IP?
HTTP is not more "fundamental" than SMTP in some universal sense. But
HTTP is the web's protocol and it was designed for the Web. In
particular, it was designed to work with URIs. Web services that are
built around an SMTP model or RPC will find they have trouble
integrating with other web services because how do you refer to data
objects in those other services? Not through URIs!
For instance, what is the URI for IBM in the UDDI web service?
Paul Prescod
|
