Remi Delon wrote:
On our own servers we've been using CGI connectors (wkcgi,
Zope.cgi), which seem fast enough, and of course won't be crashing
Apache.
Yeah, but we wanted a somewhat "standard" way of talking to Apache and
most frameworks do come with a small HTTP server, so that works fine for
On our own servers we've been using CGI connectors (wkcgi, Zope.cgi),
which seem fast enough, and of course won't be crashing Apache.
Yeah, but we wanted a somewhat "standard" way of talking to Apache and
most frameworks do come with a small HTTP server, so that works fine for
us and it also compl
The CP-Location trick is not needed (I should remove it from this page
as it confuses people).
Hmm, I wrote that part of the page. My specific reason for using a
custom header is that it's the only way I can see to locate a CherryPy
application *not* at the root of a virtual host.
Maybe we should c
Titus Brown wrote:
-> I use relative URLs because of this, but I understand why this might
-> cause you problems. Perhaps we can add a 'root namespace' parameter
-> to WSGI...
duh.
That's what SCRIPT_NAME is.
BTW, an interesting (I think) pattern that I found, with a hook I added
to wsgikit.urlp
-> I use relative URLs because of this, but I understand why this might
-> cause you problems. Perhaps we can add a 'root namespace' parameter
-> to WSGI...
duh.
That's what SCRIPT_NAME is.
Sorry.
;)
--titus
___
Web-SIG mailing list
Web-SIG@python.o
-> > The CP-Location trick is not needed (I should remove it from this page
-> > as it confuses people).
->
-> Hmm, I wrote that part of the page. My specific reason for using a
-> custom header is that it's the only way I can see to locate a CherryPy
-> application *not* at the root of a virtual
Remi Delon wrote:
On our own servers we've been using CGI connectors (wkcgi, Zope.cgi),
which seem fast enough, and of course won't be crashing Apache.
Yeah, but we wanted a somewhat "standard" way of talking to Apache and
most frameworks do come with a small HTTP server, so that works fine for
u
On Thu, 31 Mar 2005 11:56:33 +0100, Remi Delon <[EMAIL PROTECTED]> wrote:
> The CP-Location trick is not needed (I should remove it from this page
> as it confuses people).
Hmm, I wrote that part of the page. My specific reason for using a
custom header is that it's the only way I can see to loca
Ian Bicking wrote:
Remi Delon wrote:
I'm wondering -- and this is mostly directed to the hosting providers
(Remi, Sean...) -- what are the problems with providing
commodity-level hosting for Python programs? I can think of some,
but I'm curious what you've encountered and if you have ideas abou
Remi Delon wrote:
I'm wondering -- and this is mostly directed to the hosting providers
(Remi, Sean...) -- what are the problems with providing
commodity-level hosting for Python programs? I can think of some, but
I'm curious what you've encountered and if you have ideas about how to
improve t
This allows us to use the trick described on this page:
http://www.cherrypy.org/wiki/BehindApache (look for "autostart.cgi") to
have Apache restart the server automatically if it ever goes down.
A main disadvantage of using apache to start the HTTP server is
process UID. The HTTP server will be s
On Tue, 29 Mar 2005 10:43:55 +0100, Remi Delon <[EMAIL PROTECTED]> wrote:
> This allows us to use the trick described on this page:
> http://www.cherrypy.org/wiki/BehindApache (look for "autostart.cgi") to
> have Apache restart the server automatically if it ever goes down.
>
A main disadvantage
I'm wondering -- and this is mostly directed to the hosting providers
(Remi, Sean...) -- what are the problems with providing commodity-level
hosting for Python programs? I can think of some, but I'm curious what
you've encountered and if you have ideas about how to improve things.
Some things
> * Long running processes are hard to maintain (assuming we rule out
> CGI). Code becomes stale, maybe the server process gets in a bad state.
>Sometimes processes becomes wedged. With mod_python this can effect
> the entire site.
I've been extremely impressed at how well Python's VM doe
Speaking as a Tummy.com customer, I have a virtualized linux server. My
processes are isolated from Tummy's other clients on that piece of
hardware at the OS level. I still face the same issues with
long-running processes, but at least it is all from code that I maintain
on a server image that I
michael bayer wrote:
if you run multiple virtual hosts out of Apache, mod_python by default
creates new subinterpreters, via Py_NewInterpreter, for each virtual
host. this can also be set up per apache directive, an arbitrary name,
or within individual directories.
although how well Py_NewI
if you run multiple virtual hosts out of Apache, mod_python by default
creates new subinterpreters, via Py_NewInterpreter, for each virtual
host. this can also be set up per apache directive, an arbitrary name,
or within individual directories.
although how well Py_NewInterpreter separates
I'm wondering -- and this is mostly directed to the hosting providers
(Remi, Sean...) -- what are the problems with providing commodity-level
hosting for Python programs? I can think of some, but I'm curious what
you've encountered and if you have ideas about how to improve things.
Some things
18 matches
Mail list logo
