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

[Rene Dudfield]

I have no idea what any of these template specifications are about yet.

I do value your approach to being inclusive, and allowing as many as
possible styles to play.

As you have said yourself, I think many people can not understand what
everyone is talking about.  So until people have something written
down most of the rest of us will have no idea what anyone is really
talking about.  Being able to keep up with 100ish emails is no easy
task.

At least a gathering of the use cases has been happening.  Which is
nice.  Once a spec is written up, we can all look at which use cases
are not allowed with whatever spec is proposed.





On 2/7/06, Phillip J. Eby <pje at telecommunity.com> 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/renesd%40gmail.com
>