Mike Orr wrote: > A middleware bundled with library components (importable functions) > certainly makes sense, since it gives more flexibility to the > controller. I was not complaining about a WSGI-library hybrid, but of > an idiosyncratic library that avoided WSGI for no good reason. The > 'email' library in another message, presented as superior to a WSGI > alternative, is not an example. (1) the 'email' package doesn't do > anything web specific, (2) it doesn't carry state across requests or > sessions. Therefore it has no reason to be middleware. But anything > that's related to identity or sessions or redirects or page wrapping > or cookies etc should probably be WSGI'ified unless there's a good > reason not to. "Useful in only one application or framework" would be > a good reason not to. "Not reinventing the wheel (even if we already > have)" would be a good reason to.
Indeed, the email library was a poor choice for an example. > And I can see the point for turbogears.request.wsgi [1] or such so > you don't have to pass the environment around everywhere. The point > of middleware is to be framework-neutral, not to force everything > through the environment. Yup, though if TG is increasing Paste-compatibility at the same time, some Paste middleware perhaps similar to the paste.deploy.config middleware could be used to 'register' such thread-locals (mainly because it can be tricky to clean-up at the end of a wsgi app request). Lots of places for re-use. :) - Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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 -~----------~----~----~----~------~----~------~--~---
