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

[Brett Haydon]

Not quite sure what you've got happening there..

but look at www.modpython.org for an apache/python solution.

bbhaydon

"Eugene Leitl" <Eugene.Leitl at lrz.uni-muenchen.de> wrote in message
news:mailman.984150374.638.python-list at python.org...
>
> 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
>
>