From: Roy T. Fielding (fielding@kiwi.ICS.UCI.EDU)
Date: Fri Aug 18 2000 - 19:14:28 PDT
>> Definitely got the One Way Web right. My question is, can the One Way
>> Web evolve into the Two Way Web?
>>
>> When Rohit talks about the "Two Way Web", he discusses "the belief that
>> HTTP has three flaws, so fundamental they're rarely even noticed:
>> 1. It's ONE-WAY data flow, requiring clients to initiate
Yes, because everyone knows that servers can be trusted to run your client.
>> 2. It's ONE-TO-ONE data flow, preventing group synchronization or services
Yes, because we all know that broadcast scales really well.
>> 3. It's ONE-SHOT data flow, only reliable if the origin server's up"
Yes, because we all know that people don't need an authoritative answer
to a request, and figuring out how to replicate everyone's ephemeral content
(along with a reliable, non-single-point-of-failure, free service for
obtaining alternate access to content) shouldn't be a hard problem to
solve. What social problem?
Yes, I am being sarcastic.
In HTTP, the distinction between a client and a server is limited to the
role they play for a specific connection. There has never been a limit
on the ability of software acting as a server to establish a separate
connection to the software acting as the client which would reverse those
roles. The reason they don't is because the application for which HTTP
was designed doesn't need such a connection, and reliance on it would
make the overall system less capable of dealing with firewalls.
In other words, it would be a bad design trade-off.
Second, HTTP does support one-to-many data flow via proxies (group
annotation being the common example) and network gateways (what WREC
is now calling surrogates). It isn't a common feature on the Web
because of the privacy concernes.
Third, I'd rather have a low-entry-barrier system that works 96% of
the time [that figure is from my MOMspider user reports] than a
never-deployed system that works 100% of the time.
>Rohit completely right on this stuff, but I add one less abstract problem -
>browser centricity of proxy servers.
>
>Proxies unilaterally disconnect long lived streams at a timeout, usually
>5-15 mins. Without acks it is impossible for a sender to know which
>messages were sent but not received. So an http based protocol like SOAP
>has to support retransmission by numbering packets, caching them, setting up
>some kind of ack, and manually doing reassembly. In other words, the
>browser assumptions of the infrastructure force us to reinvent TCP on top of
>HTTP as if HTTP were IP, and that leads to a situation where we get TCP,
>except slow and buggy. bleh. bleh. bleh.
No kidding. Now why is it that the Web works across HTTP?
>This must have been discussed by hard core HTTPists like Roy F. Anybody
>know what the result was?
Yes. The discussion usually goes something like this...
Your car makes for a lousy airplane.
That's because it isn't supposed to be an airplane.
Sure, sure, sure... but I want to fly to Hong Kong.
Then build an airplane.
But there are so many restrictions associated with airplanes...
you need special landing rights... they expect a competent pilot...
you can only land in a few places... and everything is so expensive.
That's because flying isn't as easy and safe as driving. Why do
you think they'll let flying cars get by with fewer restrictions?
But we have so many cars just lying about unused, and everyone
has a highway in their backyard, so obviously a car is the right way
to travel.
That's a byproduct of it being easy and (relatively) safe to drive,
not a statement about the universal applicability of cars.
But I'm pretty sure that if we add wings here, and a tail over there,
and call the driver a pilot, that this is the only way to go.
*sigh* ... Fine, then. When you get back from Hong Kong we'll
talk about making it part of the standard.
Application-layer protocols provide a means for components within a
network-based architecture to communicate. 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 -- go screw with someone else's buzzword.
I hear that the OMG has plenty that aren't being used much at all.
....Roy [who apparently needs a beer]
This archive was generated by hypermail 2b29 : Fri Aug 18 2000 - 19:18:24 PDT