From: Lucas Gonze (firstname.lastname@example.org)
Date: Sat Aug 19 2000 - 15:19:52 PDT
> Your car makes for a lousy airplane.
> That's because it isn't supposed to be an airplane.
No argument from me there. The problem is that the complete total utter
massive dominance of HTTP makes it the only practical protocol for
applications that have more to do with RPCs than hypertext. I am not
advocating the situation, I am pointing out that it exists. If you don't
believe me take a poll on the list right now to see how many people believe
in putting web servers on the client side to get two way messaging.
The main reason it is the only practical protocol is that it can break
through firewalls. Breaking through firewalls is probably a bad thing, but
that doesn't matter - developers make their own decisions. If they can't
get through the firewall any other way then they will overload HTTP.
Because HTTP is bad at RPCs what we are getting is slow and unreliable apps.
Back to Adam's original question: can the One Way Web evolve into the Two
Way Web? I'd say that, because HTTP is bad at RPCs, the One Way Web has to
evolve into the Two Way Internet. Let HTTP keep doing what it is designed
for, which is browser/server interactions. To evolve we need either an HTTP
2.0 that properly supports RPCs or we need new protocols that can also break
> Design the protocol based
> on how you want the components to be constrained, and they will have
> no choice but obey the architecture. Complaining about the same
> constraints when trying to use the protocol within a completely different
> architecture is inane
I can't go there with you. Developers serve users; protocol designers serve
This archive was generated by hypermail 2b29 : Sat Aug 19 2000 - 12:29:17 PDT