[
Lists Home |
Date Index |
Thread Index
]
> As an simple example, take any business transaction more long-winded
> than typing in credit card number, hitting a submit button and getting
> a near instant response. Perhaps the transaction has to be approved by
> a person, so processing takes a couple of hours (maybe much longer if
> it arrives late on a Friday evening). What might the requestor want to
> do in the interim? Disconnect from the network? Move to a different
> endpoint? Or perhaps there's a network partition during the
> transaction, or an unfriendly intermediary decides to time out an
> apparently idle connection.
>
> HTTP just wasn't designed for that kind of communication model.
You'd be surprised. 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 (though not, I believe,
for the example you describe above).
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..
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@planetfred.com
http://www.markbaker.ca http://www.planetfred.com
|
