On Feb 5, 11:51 pm, "Damjan" <[EMAIL PROTECTED]> wrote:
> BTW In the near feature you could use mod_wsgi
> http://www.dscpl.com.au/wiki/ModWsgi
> . It's simpler and easier to configure than mod_python (and a bit
> faster).
I'm surprised by the comment "It's simpler and easier to configure"
since no real documentation has actually been made available yet
saying how it is done. ;-)
Even if mod_wsgi is easier than mod_python to setup and makes the task
of using Python web frameworks a bit easier through effectively being
a plug and play server solution for WSGI components, this doesn't
necessarily mean that no work is required to get TurboGears to work
with it.
The ideal general solution would be that all that is required is to
create an appropriate WSGI application object corresponding to the
TurboGears application. The important thing is that it should accept
all its configuration or pointers to its configuration through the
WSGI environ dictionary. There preferably should not be a requirement
for any separate steps outside of the WSGI model, otherwise there
still has to be a separate WSGI middleware adapter to get it to work
which is extra work for a user to write themselves if it isn't just a
part of TurboGears.
Since TurboGears uses CherryPy, the issues may not even arise directly
because of TurboGears but because of CherryPy. This is because
although the following creates a WSGI application object with CherryPy
3.0:
import cherrypy
class Root(object):
def index(self):
return 'Hello World!'
index.exposed = True
application = cherrypy.Application(Root(), None)
If you plug that into mod_wsgi it doesn't work with the CherryPy layer
giving back a 503 Service Unavailable error. This is because one has
to do an additional step currently of starting the CherryPy engine.
Ie., somewhere something has to have run:
cherrypy.engine.start()
There is a Trac ticket for CherryPy at http://www.cherrypy.org/ticket/651
which covers avoiding the need to start the engine when working
through WSGI, what I don't know is how this is at all relevant to
TurboGears as I don't really know how initial initialisation of
TurboGears is done. The important thing is that if there are such
separate steps required, they should be done transparently within the
WSGI TurboGears application and whatever is dispatching to the WSGI
TurboGears component shouldn't need to know about.
Apart from the issue of making TurboGears playing nice as a WSGI
component, the other issue is that mod_wsgi still relies on Apache and
thus you still can have multiple child processes in which concurrent
versions of the same TurboGears application is run. Thus, if there are
problems to be solved with the database layer when using mod_python
and multiple Apache child processes, the same problem is going to have
to be addressed for mod_wsgi to work well.
Anyway, I could just be talking crap as TurboGears is the one major
Python web framework I know least about. :-)
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
