This is really great. I wish I could come up with some creative new ways to say thank you, but... thank you :-) Shel
On Nov 21, 6:10 pm, Martin Gregorie <mar...@address-in-sig.invalid> wrote: > 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
