building a web interface
martin at address-in-sig.invalid
Mon Nov 22 03:10:26 CET 2010
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
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
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
More information about the Python-list