2010/3/4 David <[email protected]> > mod-wsgi makes your wsgi apps persistent. In one mode, they are > embedded in the Apache server directly, and in the other mode they run > daemonized as their own processes. In either mode, having the wsgi > app (and its dependency modules) persistent in memory allows a faster > response than cgi can do; cgi involves loading the app from disk for > each invocation. >
Ok, those are good features. In other words, the difference is just like the one between mod_php5 and php5-cgi. CGI is "universal" but has less features and is slower. > > See: http://code.google.com/p/modwsgi/w/list for abundant docs on the > module. > Yes, i'm reading the documentation. -- > [email protected] > Rdbhost -> SQL databases as a webservice [www.rdbhost.com] > Wow! It's just i was looking for! 2010/3/4 Graham Dumpleton <[email protected]> > > WSGI itself is an interface definition and nothing more. There are > many implementations of the WSGI interface and wsgiref and mod_wsgi > are just two options. This is the info i was looking for. They're two INDIPENDENT options. As wsgiref is embedded in python and mod_wsgi works with python I was thinking mod_wsgi was a type of *wsgiref* implementation for apache. > A WSGI application doesn't need to use wsgiref. > In fact the wsgiref module is simply that, a very simple reference > implementation to illustrate how WSGI works and also contains some > validation tools for determining whether your WSGI application is > behaving correctly in respect of the WSGI interface standard. > Yes but it also contains a CGI server that can make python working with every webserver that can handle cgi scripts, this is the very important feature! > The wsgiref module also contains a CGI/WSGI bridge and even if you > need the ability to use WSGI on top of CGI, you don't need to use that > CGI/WSGI implementation. In fact, the WSGI PEP at > 'http://www.python.org/dev/peps/pep-0333/' contains a sample CGI/WSGI > bridge as do some other packages as well. > This is interesting. Let me read that page. > > In summary, the implementations of hosting mechanisms are meaningless. > The important thing is the WSGI interface definition itself. You will > find many hosting mechanisms that support that interface. Each has > different qualities and features available and/or work within > different web server environments, or even provide their own web > server. You need to look at what hosting environment you need to work > in and choose the appropriate WSGI hosting implementation that suits. > Right. Actually i'm not interested in the WSGI interface, but just in its implementations! > > So, many options to choose from. There is no one right solution. So > long as your application conforms to WSGI interface specification, you > can technically use any of them. Whether your application itself > though will work with all is a different matter. By that I mean > performance issues for CGI solutions, and multithreading issues if > using a system which uses threads instead of or in addition to > processes. > And this is was i was asking in my first post. I was trying to find out differences between different implementations. Thankyou Graham Thankyou David Giorgio -- -- AnotherNetFellow Email: [email protected] -- You received this message because you are subscribed to the Google Groups "modwsgi" 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/modwsgi?hl=en.
