Two great posts from Christian

Robert Brewer wrote:
> Ben Bangert wrote:
>
> > I'm not making arguments either, just
observations.
>
> OK. I must have inserted my own "CherryPy needs
to change" insinuation.

Well, first of all thanks to Ben for his message,
adversarial as it is.
 It's touched off a very useful, and needed discussion. 
The main point
is that CP *does* need to change.  It would need to change
regardless
of WSGI, but WSGI is an important catalyst for needed
change.  I think
a lot of the needed change is exactly along the lines of
Robert's
statement later on...

> Given the design choice of whether to provide a given
feature as a library call:
>
>     import lib
>     def page(self):
>         lib.feature(params)
>
> ...as a filter:
>
>     [/page]
>     feature_filter.on = True
>
> ...or as middleware:
>
>     import lib
>     wrapped_app = lib.featureMiddleware(simple_app,
global_conf)

I'm not sure why your top option is not also middleware.

> ...I tend to prefer one of the first two options. The
library call allows per-call configuration right next to the
call itself. The filter and middleware allow a feature to
apply more broadly. I fully expect CP 3 will offer all such
features in libraries. A "filters" module will
wrap many of them so that they can be used as filters. A
"wsgi" module will offer wrappers for many of
them so they can be used as WSGI apps or middleware
components.

This improved modularization for CP 3 is essential.  This is
what needs
to change.  CP is a bit too gnomic right now.  The core
engine does a
lot of cool things, but much off it is not readily exposed
for the
developer.  A good example is the long IRC thread I had
recently about
re-using the path/object mapping.  I I want to use deault()
for one
path segment but then forward the processing back to CP for
segments
farther to the right, I have no idea how to do so.  The path
traversal
algoritms ahould be expsed as modularized, dependency-free
(as much as
possible), well-documented components.  If not, CP *is*
forcing the
user to do things its way.

Note that I never mentioned WSGI in the above para.  CP's
need for
componentization is independent of WSGI.  However, I think
WSGI is
*very* important.  It represents the thoughts of *many*
smart people on
how to compoentize Python Web apps, given experience with
the many
frameworks that preceded it.  It boggles my mind that anyone
would
minimize this effort, as Remi does.  I think Christian's
and Robert's
attitide towards WSGI is understandable: some skepticism,
but a
willingness to learn lessons and build bridges.  I think
Remi's
attidude on the other hand is really detrimental to CP. 
Remi attacks
straw man "miracles" of WSGI, but I've never
seen anyone claim thet
WSGI will do anythign miraculous.  It makes it look as if
CP's lead
developer has his head stuck firmly in the sand.  I worry a
bit that
this might get in the way of the CP refactoring that is
required in CP
3.0.

In short: WSGI is not a matter of miracles: it's a matter
of concerted
thinking by the community of how Python Web frameworks can
be carefully
componentized.  As such, it provides some benefits but no
panacea.  I
think any observer understands that, and understanding that,
would look
at some of the deficiencies of CP 2.2 and expect commitment
to improved
modularization in CP 3.0.  If some of the ideas and code
along that
path comes from the WSGI crowd, I think most observers would
feel that
the CP crowd would do well to gratefully accept it, and if
there is a
perception of stonewalling instead, people *will* certainly
begin to
drift away.

--
Uche Ogbuji
ucheogbuji.net  http://uche.ogbuji.net  
http://copia.ogbuji.net
Work: uche.ogbujifourthought.com   http://Fourthought.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---

> This improved modularization for CP 3 is essential. 
This is what needs
> to change.  CP is a bit too gnomic right now.  The core
engine does a
> lot of cool things, but much off it is not readily
exposed for the
> developer.  A good example is the long IRC thread I had
recently about
> re-using the path/object mapping.  I I want to use
deault() for one
> path segment but then forward the processing back to CP
for segments
> farther to the right, I have no idea how to do so.  The
path traversal
> algoritms ahould be expsed as modularized,
dependency-free (as much as
> possible), well-documented components.  If not, CP *is*
forcing the
> user to do things its way.

I completely agree here. Some improved modularization is
indeed needed.
It is already possible to change the dispatching algorithm
and to call
the object mapping function on your own but it could be made
easier and
it's not well documented.

> Note that I never mentioned WSGI in the above para. 
CP's need for
> componentization is independent of WSGI.  However, I
think WSGI is
> *very* important.  It represents the thoughts of *many*
smart people on
> how to compoentize Python Web apps, given experience
with the many
> frameworks that preceded it.  It boggles my mind that
anyone would
> minimize this effort, as Remi does.
> I think Christian's and Robert's
> attitide towards WSGI is understandable: some
skepticism, but a
> willingness to learn lessons and build bridges.  I
think Remi's
> attidude on the other hand is really detrimental to CP.
 Remi attacks
> straw man "miracles" of WSGI, but I've
never seen anyone claim thet
> WSGI will do anythign miraculous.
>  It makes it look as if CP's lead
> developer has his head stuck firmly in the sand.  I
worry a bit that
> this might get in the way of the CP refactoring that is
required in CP
> 3.0.
>
> In short: WSGI is not a matter of miracles: it's a
matter of concerted
> thinking by the community of how Python Web frameworks
can be carefully
> componentized.  As such, it provides some benefits but
no panacea.  I
> think any observer understands that, and understanding
that, would look
> at some of the deficiencies of CP 2.2 and expect
commitment to improved
> modularization in CP 3.0.  If some of the ideas and
code along that
> path comes from the WSGI crowd, I think most observers
would feel that
> the CP crowd would do well to gratefully accept it, and
if there is a
> perception of stonewalling instead, people *will*
certainly begin to
> drift away.

Well, what I'm basically saying is "I don't really
believe that WSGI
will help python web development. But CP is a team effort
with lots of
users so we're doing our best to accomodate those of us who
might want
to take advantage of what WSGI brings". I don't see
anything wrong with
that position ...

What I don't like is people coming here and basically
saying "rewrite
CP using WSGI everywhere, *or else* ..."

As for the "miracles" that they claim WSGI will
deliver, I'm the one
who called them "miracles" because I don't
think that WSGI will deliver
what they claim it will.

But as Ian said, there is no point in having some
long/abstract
discussion over the benefits/drawbacks of WSGI.

Let's talk again in 6 months or a year and see if WSGI has
helped us
come up with better tools for python web development and if
these tools
have attracted more web developers to python ...
I doubt it and like I already said, I think that all this
time and
energy would be better spent in helping some existing tools
like
TurboGears, Django or CherryPy directly, because these are
the tools
that will make everybody's life easier and attract more
people to
python web development.

Remi.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---