building a web interface

[Shel]

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... at 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       |