[EMAIL PROTECTED] (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. -- http://mail.python.org/mailman/listinfo/python-list