On Thu, Feb 13, 2014 at 4:57 AM, Michael Torrie <torr...@gmail.com> wrote: > It's unclear of what you are really trying to do, though. Doing as you > propose to have a python server communicating with a web front-end is > going to be a lot harder than you think. ... > Some kind of CGI system. Or roll your own with TCP/IP Sockets. ...
There's a fundamentally tricky part to this, which is that the Python interpreter is stateful and HTTP is stateless. You can't usefully use the Python REPL as anything more than a calculator without maintaining a dedicated process for each connected client... and HTTP doesn't have a concept of "connected client". (Cookies will let you recognize a client as the same one who spoke to you earlier, but you'd need some kind of timeout system to flush out the ones who've gone away. Set the timeout too short and you annoy everyone until they don't use it; set it too long and you saturate your server with myriad processes that aren't needed any more.) So you may have to look into a non-HTTP way of communicating between the server and the client. At the moment, there aren't many ways you can do that; you can either plonk down a non-JS object (eg Flash or Java), or you can use HTML5 WebSockets (which aren't supported everywhere); either way, you have to worry about what clients will support it, how it traverses firewalls, etc, etc. Oh, and there's another tricky bit. Python isn't secure. Running it on your server means opening yourself up to all sorts of crazinesses - if nothing else, you need a way to kill the server process and restart it, when you get something stuck somewhere (trust me, you will - it doesn't require malice!). Using a web browser as a UI is fine for some things (I wrote a command/control system for movie players that works through a browser), but it's not automatically easy. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
