On Sun, 21 Nov 2010 15:40:10 -0800, Shel wrote: > I am confused about multiple simultaneous users, which I would like to > be able to accommodate. On the db side, I have a structure to store > data for each user, and know a bit about selectively locking data, > although I have not implemented that yet, so will see what happens. > I realise what I wrote last night wasn't all that clear. Terms: 'transaction' and 'session'.
A web server 'transaction' consists of a request from a user that results in a page being sent to the user. That's it. It is an isolated action that does not depend in the web server knowing anything about the user because all the information it needs to decide which page to send was supplied when the user sent in the URL of the page. Now if the user clicks on a link on that page, his browser sends the URL in the link to the server, which in turn fishes out another page and sends it back to the user. As far as the server is concerned, there is no connection whatever between the two requests: either or both URLs could have been copied from a piece of paper for all it knows or cares. There is no concept of context or a session involved. A 'session' involves context. Think of what happens when you login to a computer. That starts a login session that has context: the computer now knows who you are and provides context by connecting you to your login directory and opening some work space which is used to remember which directory you're in, what commands you issued (so you can look at the history), etc. The session and its context persists until you log out. In what you're intending to do, a user will start a session by starting to use your program and that session will last until the user disconnects from the session. All the web server knows is that instead of finding a page on disk some place it passes your user's request to your program and sends its output, in the form of a web page, back to the user. It does this each time it receives a request from the user because all the user's requests contain the same URL - that of your program. The server does this without knowing there is such a thing as a session or that there is any context belonging to the user. The upshot is that your program has to keep track of all the active sessions and maintain context for each active session. It also needs a way to recognise and get rid of dead sessions because sessions don't always end cleanly: the line may go down or the user may forget he was using your program and turn his PC off. For instance, if the session context has a timestamp, you might delete it after, say, 20 hours of inactivity, or when the user logs on again. If the data is sensitive, you might also force a new logon after 10 minutes of inactivity. The database is as good a place as any for keeping session and context data - if its well structured the context may well form a single (large) row on one table, but you do need a unique key for it. That could even be the login name provided you're able to include it in every page you send to the user and can guarantee that the browser will send it back as part of the next request. A hidden field on the page will do this automatically. The basic program cycle will be: - receive a request - read the context for the session - use data in the request to carry out the requested action - write the updated context back to the database - create the output page and send it to the user though of course you need additional dialogue to deal with both valid and invalid logons and logoffs. > I don't really get how multiple users work in terms of pretty much > everything else, like if the Python code is running on the server, > then... well, I just don't know. > Hopefully the above made it a bit clearer. > Maybe I should try to get it running > for multiple discrete users first, and then think about simultaneous > users, or is that a bad way to go about things? Or maybe it will start > to make more sense when I get into building the interface? Any > info/suggestions are very welcome. > For bare desktop development I would split the program into three parts: 1) the program itself, written to run a single transaction each time its called. Inputs would be the bits of the users message it needs to act on and the current session context record. 2) a testing harness that accepts user input from the console, sends output back to the console and maintains a single session context record in memory: IOW it runs your program in single user mode. 3)the web server interface which retrieves the session context record, passes it and the input to your program and, after that has run, saves the session context record and passes the output to the web server for delivery to the user. This way both 2 and 3 can be developed against a really simple 'do almost nothing' version of 1 while that in turn can be developed and tested on your desktop using 2 and later be dropped into the web server with 3 as its interface. I have an in-house copy of Apache that I'd use to develop your type of program. Its used for all my website development so that nothing gets loaded onto my public sites until its been properly checked out here. You can do the same if you can find and install a really simple web server that would run on your PC together with a local copy of MySQL - of course! Given this setup you can use your usual web browser to talk to the local web server. If you can run all that you won't need 2 because you can have your simple web server and program running in a console window on your desktop PC while you hammer it from your web browser. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | -- http://mail.python.org/mailman/listinfo/python-list