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@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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ 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