On Thu, Apr 14, 2011 at 2:53 AM, Graham Dumpleton < graham.dumple...@gmail.com> wrote:
> On 14 April 2011 16:57, Alice Bevan–McGregor <al...@gothcandy.com> wrote: > >> 3. Define how to get the WSGI app. This is WSGI specific, but (1) is > >> *not* WSGI specific (it's only Python specific, and would apply well to > >> other platforms) > > > > I could imagine there would be multiple "application types": > > > > :: WSGI application. Define a package dot-notation entry point to a WSGI > > application factory. > > Why can't it be a path to a WSGI script file. This actually works more > universally as it works for servers whichttps:// > bitbucket.org/ianb/silverlining/src/tip/silversupport/appconfig.py#cl-298hmap > URLs to file based > resources as well. Also allows alternate extensions than .py and also > allows basename of file name to be arbitrarily named, both of which > help with those same servers which map URLs to file base resources. It > also allows same name WSGI script file to exist in multiple locations > managed by same server without having to create an overarching package > structure with __init__.py files everywhere. > The main way to load applications in Silver Lining is basically like a wsgi script; or more specifically a file that is exec'd and it looks specifically for a variable application. Silver Lining also supports Paste Deploy .ini files, but in practice this doesn't seem that important (after all you can run paste.deploy.loadapp in the script). In this case the mapping of filenames and use of extensions doesn't matter, as applications would not be compelled to use any particular extension, and traversing into the application wouldn't make sense. Another thing that is common with .wsgi files (and similarly for App Engine script handlers) is that developers do all sorts of initialization (like changing sys.path etc). This makes it hard to access the application except through that entry point, thus requiring all access to be in the form of URL fetching (again like App Engine). So on one hand I like the .wsgi file technique; on the other hand I don't ;) Most of what we're talking about is, in Silver Lining, implemented in silversupport.appconfig. Particular pieces: Loading the application: https://bitbucket.org/ianb/silverlining/src/tip/silversupport/appconfig.py#cl-310 Set up sys.path: https://bitbucket.org/ianb/silverlining/src/tip/silversupport/appconfig.py#cl-298 Set up services: https://bitbucket.org/ianb/silverlining/src/tip/silversupport/appconfig.py#cl-223 There's going to have to be a bit of indirection with services, as an application is asking in effect for an interface, and each tool may implement that interface differently (maybe a package could provide sort of an abstract base class for these, but the specific implementation is going to be very deployment-tool-specific). Also generally more is setup before the .wsgi-like script is executed in Silver Lining than in mod_wsgi. Well, here's the actual mod_wsgi-.wsgi script that Silver Lining uses: https://bitbucket.org/ianb/silverlining/src/8597f52305be/silverlining/mgr-scripts/master-runner.py But it's a bit confusing because it translates a bunch of variables set by the rather obtuse Apache config to figure out what application to run and how. But sys.path is fixed up, services are "activated" (mostly meaning they set their environmental variables), stderr/stdout is fixed up (since there's some sense of logging in the system, I felt there was no reason to bar use of those streams), and then some tool-specific stuff is done (e.g., fixing up the request URL given the Varnish setup). These are the examples of the kind of detailed specification of parts of the environment that I guess we need to have -- it's really how the entire process is setup that we need to specify, not just the WSGI request portion (which at least we don't have to specify much since that's done). Ian
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com