[
Lists Home |
Date Index |
Thread Index
]
> I wouldn't. But it's one thing to say that HTTP, along with lots of
> supporting infrastructure,
I tried to stay away from saying "lots". It doesn't need lots. It's
mostly there already.
> 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.
There are things HTTP isn't suitable for, but there are less things
that REST isn't suitable for. For example, HTTP doesn't do a great
job at streaming, but another protocol obeying the constraints of
REST could.
> > The architectural style used to craft HTTP is certainly capable of a
> > lot more than what HTTP can currently do. So you'd need extensions
> > for some things
>
> Then it's not HTTP any more.
When I use a new media type, is it still HTTP? Of course. HTTP
supports extensibility on many levels; content formats, transfer
encodings, headers, methods, status codes, etc.. To say that using
these extensions is no longer HTTP, is incorrect.
> > (though not, I believe, for the example you describe above).
>
> Disconnected operation (whether deliberate or accidental) and
> endpoint mobility are the tricky cases. It can be done, but it's not
> pretty.
A local proxy could, if there's a disconnect, queue the request and
return a 202 (Accepted) to the client, thereby informing the client
that the result of the invocation will be returned later. In the
body of the 202, the proxy could return its own URI that represents
the completion of the invocation.
Endpoint mobility, if I understand you correctly, isn't tough. As HTTP
is a state transfer protocol, bringing an endpoint up to state with
another just means transferring state between endpoints. This can be
done with a GET from one to the other (web server on the "client"), or a
PUT in the other direction (where each is likely to be a compound
document, or perhaps just pipelined) - depends what you need.
> Other protocols (or hybrids, HTTP+SMTP to name only the most
> obvious example) do a better job.
I'd have to see it to know.
> > 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 more general. It can submit data like SMTP, with POST. It can
retrieve information like POP3 with GET. It can store files like FTP
with PUT. This is not an accident.
Shall we take this one offline too? 8-) It's surely off topic by now.
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@planetfred.com
http://www.markbaker.ca http://www.planetfred.com
|
