Top down Python

[Chris Angelico]

On Thu, Feb 13, 2014 at 4:57 AM, Michael Torrie <torriem at 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