On 5/13/05, Dominique Boucher schemeway@sympatico.ca wrote:
1 or 2 seconds for a web server is a HUGE delay. Suppose that you try to serve hundreds of pages simultaneously... In my application domain (speech-enabled applications), such delays are unacceptable.
Its pretty unacceptable in any web app. Also 450k per page is way to much bandwidth usage. However, Marc never said this was a production quality web server. Neither does he claim to be an expert in web systems. The only thing he ever said is that this would be a good place to start, and it is.
I know Marc is a not a big proponent of the other web-continuation approach (the one taken by PLT Scheme, for example) that keeps the continuation on the server. But for some domains like mine, there is no need to worry with the back-button problem. So the other approach is viable and would not incur this serialization penalty.
Even if you do need to worry about the back button its pretty trivial to fix. Just implement sessions, store the continuation in the session and write out a key you have attached to that continuation in a form somewhere. Initialy you can store the session ids in a cookie, later on you can implement more advanced things like URL rewriting and what not. All of these problems where solved quite some time ago, its just a matter of applying those lessons to this system.
As for storing system data on the client, that's never a good idea for reasons I hope are obvious.