[Web-SIG] Bowing out (was Re: A trivial template API counter-proposal)

[Jim Fulton]

I'm not sure what you're talking about here.  Are you talking about
WSGI? Or the templating effort?  I've tuned out the templating discussion.

I think you and others did a fantastic job with WSGI. (Based on my
experience I do think it needs more work in the future, but that's
beside the point.)  Despite some skepticism about the templating
effort, I certainly planned to evaluate it when it settled down.
For the record, I am very interested in inclusive specs and
other means to collaborate.  Keep up the good work!

I do think that the pioneering work you are doing with setuptools
is far more important for Python, so I'd be happy to see you focus on
that. :)

Jim


Phillip J. Eby wrote:
> At 08:02 PM 2/5/2006 +0000, Alan Kennedy wrote:
> 
>>Looking at this in an MVC context, the application is responsible for
>>populating the Model (user namespace), and selecting which View
>>(template<->media-type) is suitable for return to the user. Templates
>>should not vary media types. HTTP headers do need to be set for
>>different templates/media-types. But that should be the responsibility
>>of the HTTP application, not the template, which should be unaware of
>>the application contect in which it is running, except for the contents
>>of the Model/user-namespace.
> 
> 
> As soon as you start talking about what templates should or should not do 
> (as opposed to what they *already* do), you've stopped writing an inclusive 
> spec and have wandered off into evangelizing a particular framework philosophy.
> 
> OTOH, before I first proposed WSGI in 2003, nobody here seemed especially 
> interested in writing inclusive specs anyway, and I rather get the 
> impression they still aren't now, my "insistence" (as Ian calls it) 
> notwithstanding.
> 
> What I've been trying to do with both WSGI and with this spec is to create 
> something that deals with the *actual* complexity and diversity of Python 
> web frameworks as they exist today, rather than reducing the diversity to 
> match whatever the currently popular paradigm is.  This wasn't a popular 
> approach when I introduced WSGI, either, but in the case of WSGI it was 
> easy to point to all the previously-failed attempts at standardizing 
> request/response objects due to people not taking backward compatibility 
> into account.
> 
> At this point it has become clear to me that even if I spent my days and 
> nights writing a compelling spec of what I'm proposing and then trying to 
> sell it to the Web SIG, it would be at best a 50/50 chance of getting 
> through, and in the process it appears that I'd be burning through every 
> bit of goodwill I might have previously possessed here.  And, although I 
> believe that the approach currently being taken to this spec is divisive of 
> the community, I have to admit that since my attempts at education about 
> the issues hasn't been particularly successful, it would appear that 
> continuing to argue about it is no less divisive than what I'm arguing 
> against.  (For that matter, it's not even clear to me any more that most of 
> the people on whose behalf I'm fighting would even realize yet why the 
> future I want would be beneficial for them.)
> 
> I really expected more people to see the benefits of the WSGI embedding 
> approach, though, and although I've gotten a few private mails of support, 
> it isn't anywhere near the level I thought it would be.  Given the intense 
> pressure that some parties are putting on having a spec *right* now, I 
> don't feel that I can reasonably deliver a competing spec without 
> interfering with my work and personal commitments in the next few 
> weeks.  Since I've already been using most of my "Python community 
> contribution" time in the last week arguing about this, at this point it 
> seems the community would be better served by me devoting that time to 
> working on setuptools, rather than continuing to fight for a vision that 
> hardly anybody else believes in.  And, I'd rather save whatever karma I 
> have left here for something with a better chance of success.
> 
> Good luck with the spec.
> 
> 
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/jim%40zope.com


-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org