[Web-SIG] Standardized template API

[Phillip J. Eby]

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.