architectural issues cot'd; which http server to embed?

[Eugene Leitl]

I haven't received much feedback on the last architectural query yet,
as most of you people are probably on the conference. Still, here's 
goes.

I've been fooling around with diverse http servers written in plain (i.e.
containing no components written in other languages) Python (specifically,
CPython. Perhaps threaded Python, if this doesn't limit my options in
regard to portability).
 
I have (in my head, at least) a multi-component (XML-talking server-client
(sockets)) architecture driven via a web front (browser plugin or Java
client) end by user queries.  This will work transparently, whether run
locally, or on another machine on the network. I don't need the
multicomponent part so badly right now, but this is needed for a future
framework, of which this will be an integrated component.

It has to be able to run on every target which has GNU tools and TCP/IP
running on it. In practice, this will mean diverse flavors of *nix, and
Redmondware. The ideal delivery form would be a bunch of binaries bundled
in an archive, and a (frozen) GUI-based (with a shell fallback option for
the hard cases) installer written in Python. I can't install my own Python
on the client machine, and there's not enough time to do it properly (I
have certainly found enough interesting options), so I'm going to tolerate
some amount of bloat in the distribution, at least for time being.

Right now I'm researching which http server to embed (using freeze) into
the front-end. The performance requirements are quite negligable, but it
should be better non-blocking (Medusa alone won't do, will Medusa/bobo
combo? Zope is way too fat, CGIHTTPServer.py would do nicely, but it
doesn't seem to be able to support server-side Python embedding into HTML
when being frozen), as queries can take a while, and it might see more
than one user, or several queries from the same user. Otoh, I'd rather not
call multi-MByte frozen binaries via cgi-bin. It would be nice to have a
solution which allows one to embed Python code into HTML, which can get
interpreted by the Python instance which is present in the webserver, or
Python packaged in a shared library.

Another alternative I haven't researched yet is extending Python with a
minimal, well-debugged off-shelf webserver written in C. This would be
probably more palatable with passing Python scripts from cgi-bin and/or
Python embedding into server-side HTML. Discussions and pointers to code
are very welcome.

Resistancy to memory leaks is another design facet. If I can solve the
problem of long-running Python instances slowly draining memory
(considering my limited amount of clue a very real factor) by paying with
startup overhead by launching them at every query, that appears tolerable.
Even if it involves calling multi-MByte monster binaries, I'd have to bite
the bullet (I'd rather not, of course). How bad is the memory draining
issue, given debugging tool and Python2.0 cycle-elimination during gc?
Should I contemplate using a better gc?

Does this make sense, or I am missing some gotcha, or obvious alternative?
Sorry if I sound confused, I probably am. This project is rather ambitious
for my current skills, but I'd rather not tackle it in C. I'd certainly be
unable to handle this in C on the time schedule (2..4 months), so there's
not much choice, anyway.

TIA,
-- Eugene