John, Well, I see our discussion varies on one key point: Rick specifically uses the word "session" for his original requirement. The ideas put forth by Tamas and myself try to limit the creation of session ID's on the server. What you seem to put forth is limiting the server to answering one web request at a time.
So why are we so strongly arguing against you? Because HTTP is a stateless protocol. Sessions often last through multiple pages/click-throughs. So, after user Joe connects, he gets a session ID and page then his browser closes the connection. During the next 10 seconds where he is on his browser typing his login information and clicking the "login" button, anyone else can connect to the server to get a page based on your idea of a single process on the web server --- HTTP does NOT hold the connection open for him. Technically an HTTP keep-alive (a part of the HTTP v1.1 protocol) should hold the connection open but it is not a reliable theory/practice. If you develop webapps, you will need to understand that difference between a session and limiting the server to handling "NNN" requests at a time. Otherwise, it could mean the difference between a relatively secure webapp and a breach of privacy/proprietary information on your site(s) due to incorrectly secured information. Sadly, this argument is like beating a dead horse (http://www.goenglish.com/BeatADeadHorse.asp) so if you'd like to discuss this further, we should probably take it offline (since we're started writing the same arguments over and over). Regards, David --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
