At 02:48 PM 2/1/2006 -0600, Ian Bicking wrote: >Phillip J. Eby wrote: >>>My criteria is that it would be easy to implement Phillip's proposal in >>>terms of mine (and I could provide a sample implementation of that if it >>>would help), but it doesn't seem so easy to do the opposite. >> >>Actually, I believe you've got that backwards. Many things the WSGI >>embedding proposal can do, yours can't do *at all*, no matter how much >>programming you do. vars'n'strings isn't a substitute for WSGI, but it's >>easy to piggyback other payloads *out* of WSGI using file_wrapper-like >>APIs or dual-use objects with "__call__" methods. > >What exactly can't I do with a WSGI application (a specific >implementation) that uses the non-WSGI plugin API?
The "template" doesn't get to control the status or headers if all it can do is return is a string. >>>For instance, there's no way for a Cheetah template to extend a WSGI >>>application. It can extend other Cheetah templates, and even other >>>Python classes, but not a WSGI app. >> >>Provide extension APIs to allow finding other templates. Putting them in >>this context also helps make it clear that such APIs aren't -- and >>*can't* be -- universal, because the templates themselves aren't >>heterogeneous. You can't give a Cheetah template a Kid subtemplate. > >My API always indicates the type of object you are looking for, though >that may be too strict, as you don't *always* want to have a single >type. Though if there is a defined exception when a resource can't be >found, maybe that could be handled at a higher level than find_resource. I don't see what this gains over having WSGI as a universal fallback protocol in this context. You always get WSGI, and maybe it also speaks something "native" to you. >Here's a rough WSGI implementation of active pages using the resource spec: You've just presented a *convention*, not a standard. There's a big difference. Standardizing on WSGI gives a level playing field for all paradigms. Standardizing on strings clips other frameworks' wings, as your example clearly demonstrates, and forces them to reinvent wheels that we've already spent plenty of sweat and tears inventing. Why are you against this, anyway, btw? There are plenty of obvious benefits to extending the existing standard, and I'm not the only person who's pointed out that a string-oriented approach doesn't allow them to do things they want to do. There's also been scarcely any argument that you can't trivially wrap string-oriented templates as WSGI resources. So the question then boils down to this: who should be inconvenienced and what capabilities should be crippled, and by how much? Your position calls for inconveniencing nobody, but crippling any frameworks or templates that are more powerful or flexible than the ones you favor. Mine calls for a mild inconvenience to any framework that doesn't doesn't currently support embedded WSGI, but it cripples *nobody*, and encourages frameworks to *add* entirely new capabilities while enabling new kinds of WSGI-based tools. _______________________________________________ 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
