- From: Shel Kaphan <sjk@amazon.com>
- Date: Fri, 3 Nov 1995 16:15:16 -0800
- To: Brian Behlendorf <brian@organic.com>
- Cc: Koen Holtman <koen@win.tue.nl>, "M. Hedlund" <hedlund@best.com>, montulli@mozilla.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Brian Behlendorf writes: > On Fri, 3 Nov 1995, Koen Holtman wrote: > > M. Hedlund: > > >[Lou Montulli:] > > >>In fact, [Dave's proposal] reduces the capibilities such that it is nearly > > >>unusable for large scale applications such as online shopping. ... > > > > > >I disagree (as a programmer for an online shopping site). ... > > I agree. ... > Besides, hopefully this "extremely large shopping site" will be sufficiently > funded and motivated to build a shopping cart Java applet ... I've been meaning to interject a slight note of pessimism into this discussion. People building sites that require stateful interactions will not be able to completely switch over to *any* new scheme for transmitting state for a good long time. The reason is that so long as a large fraction of the browsing public uses browsers that are incapable of dealing with whatever new scheme is used (Netscape "cookies", state-info, or whatever), purveyors of interactive services will find it in their own interest to support the minimum feature set possessed by the maximum number of browsers. This means that URL-encodings are here to stay for a while. The next step beyond URL-encodings is a way to pass a session ID around without screwing with URLs, while leaving the server to manage a database. It will be fairly easy for server operators then to support hybrid schemes: browsers that support it can use a session ID, while those that don't can use URL encodings, while the server manages the state-holding database in both cases. As long as a substantial fraction of possible users and customers uses browsers with no support for special state mechanisms, server operators will have to support server- side databases. As long as they have to do this, only the most resource-rich server operators will be able to support *both* server-side databases and whatever special state-handling mechanisms are built into different clients. This will tend to slow progress. If Netscape goes its way and the rest of the world goes another way (or multiple other ways), it seems pretty clear to me that people who run servers requiring stateful interaction will just continue to do it the bad old way until the dust settles in ... a couple years ...? The same goes for expecting special Java applets to magically solve this, since it'll only work for people who have Java-capable browsers. --Shel Kaphan sjk@amazon.com
Received on Friday, 3 November 1995 16:21:51 UTC