At 07:29 AM 7/17/2005 -0400, Chris McDonough wrote: >I'm a bit confused because one of the canonical examples of >how WSGI middleware is useful seems to be the example of implementing a >framework-agnostic sessioning service. And for that sessioning service >to be useful, your application has to be able to depend on its >availability so it can't be "oblivious".
Exactly. As soon as you start trying to have configured services, you are creating Yet Another Framework. Which isn't a bad thing per se, except that it falls outside the scope of PEP 333. It deserves a separate PEP, I think, and a separate implementation mechanism than being crammed into the request environment. These things should be allowed to be static, so that an application can do some reasonable setup, and so that you don't have per-request overhead to shove ninety services into the environment. Also, because we are dealing not with basic plumbing but with making a nice kitchen, it seems to me we can afford to make the fixtures nice. That is, for an add-on specification to WSGI we don't need to adhere to the "let it be ugly for apps if it makes the server easier" principle that guided PEP 333. The assumption there was that people would mostly port existing wrappers over HTTP/CGI to be wrappers over WSGI. But for services, we are talking about an actual framework to be used by application developers directly, so more user-friendliness is definitely in order. For WSGI itself, the server-side implementation has to be very server specific. But the bulk of a service stack could be implemented once (e.g. as part of wsgiref), and then just used by servers. So, we don't have to worry as much about making it easy for server people to implement, except for any server-specific choices about how configuration might be stacked. (For example, in a filesystem-oriented server like Apache, you might want subdirectories to inherit services defined in parent directories.) >OTOH, the primary benefit -- to me, at least -- of modeling services as >WSGI middleware is the fact that someone else might be able to use my >service outside the scope of my projects (and thus help maintain it and >find bugs, etc). So if I've got the wrong concept of what kinds of >middleware that I can expect "normal" people to use, I don't want to go >very far down that road without listening carefully to Phillip. Perhaps >I'll have a shot at influencing the direction of WSGI to make it more >appropriate for this sort of thing or maybe we'll come up with a better >way of doing it. > >Zope 3 is a component system much like what I'm after, and I may just >end up using it wholesale. But my immediate problem with Zope 3 is that >like Zope 2, it's a collection of libraries that have dependencies on >other libraries that are only included within its own checkout and don't >yet have much of a life of their own. It's not really a technical >problem, it's a social one... I'd rather have a somewhat messy framework >with a lot of diversity composed of wildly differing component >implementations that have a life of their own than to be be trapped in a >clean, pure world where all the components are used only within that >world. > >I suspect there's a middle ground here somewhere. Right; I'm suggesting that we grow a "WSGI Deployment" or "WSGI Stack" specification that includes a simple way to obtain services (using the Zope 3 definition of "service" as simply a named component). This would form the basis for various "WSGI Service" specifications. And, for existing frameworks there's at least some potential possibility of integrating with this stack, since PEAK and Zope 3 both already have ways to define and acquire named services, so it might be possible to define the spec in such a way that their implementations could be reused by wrapping them in a thin "WSGI Stack" adapter. Similarly, if there are any other frameworks out there that offer similar functionality, then they ought to be able to play too, at least in principle. _______________________________________________ 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