Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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@p... http://www.markbaker.ca http://www.planetfred.com
|
