> given the complexity and weaknesses of HTTP and the wide variety of
> behavior in the deployed HTTP infrastructure, it's often more work
> to figure out and specify how to use HTTP to do something, than it
> is to design your own protocol.
No. It is hard to use HTTP to do something for which it was specifically
designed not to do well. All protocols have trade-offs in order to
match the efficiencies of the requirements at the time they were designed,
and much of HTTP's requirements centered around deployability in a
heterogeneous, multi-organizational environment. To consider a protocol's
design in isolation of its context is a poor way to create systems.
Almost all of HTTP's complexity is due to two things: MIME syntax and
the optional features of content/encoding negotiation. The only thing
hard about building an HTTP service is dealing with the raw TCP socket
handling bugs in operating systems and browsers.
> HTTP often works okay on a small scale. But I have yet to see someone
> suggest using HTTP for a widely-used protocol who truly understood
> the implications of that design choice.
HTTP is still better than any other published protocol for what it is
intended to do. Mark's point, which I think he is belaboring, is that
the same application can be designed in many ways, some of which will
work well with the Web paradigm and some of which will work against it.
That doesn't mean HTTP is the best way of implementing all applications.
It simply means that there are good uses of HTTP and bad uses of HTTP.
I'd rather burn time on replacing HTTP with something more efficient,
but for the same architecture, than waste it trying to make HTTP
efficient for all architectures.
In any case, HTTPR is a silly idea because it attempts to use HTTP as
a transport protocol, which is a total waste of bits. Firewalls exist
for a reason, and that reason won't change just because more companies
try to wedge their protocols through TCP 80. The firewalls will just
adapt to block them by content, and the resulting systems will fail in
ways that will be a customer-service nightmare. DOA, just like DCOM
over HTTP, but it will keep happening over and over again as long as
people fail to understand the reasons HTTP is not a transport protocol
(beyond the simple notion of efficiency).
....Roy