Issues of state (was: Tkinter or wxpython?)

[Paul Rubin]

claird at lairds.us (Cameron Laird) writes:
> >application in the web app model (I haven't even touched on the whole
> >stateless HTTP being mapped to a stateful environment issue, or the
> >need to manage the local web server) actually buys you anything. I
> 			.
> Go ahead:  touch on statefulness.  I've been pondering the topic
> lately, and wonder what's new on the subject.  I find it plenty
> difficult to cast this as anything but a big liability for the
> Web app team.

I'm not sure what you're getting at in this context.  You can write a
desktop app where the window system communicates with a gui toolkit
through a socket (at least that's how X windows works), or you can
write a web app where a browser communicates with an http listener
through a socket.  What's the difference, as far as application state
is concerned?  

I haven't used wxpython but for tkinter you'd typically have a gui
event loop in its own thread, communicating with the application
through queues.  Similarly you can use BaseHTTPServer to collect
browser hits and get the data out of them with the cgi module
functions before passing them to the app.  If you want to handle
multiple concurrent users you get into the usual issues of web
servers, but if you're just doing a single user web implementation as
an alternative to a desktop gui, some rudimentary locking is probably
enough to stop accidental simultaneous connections.

If the application is simple enough, you can just write it as a cgi
and keep the state in disk files.