building a web interface

[Martin Gregorie]

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       |