Two great posts from Christian

Robert Brewer wrote:
> Are you saying you heard filters are being dropped, or
are you hoping they will? If it's the former, let me set
your mind at ease and refute that. Filters will remain. Not
everything can be done in middleware. If the latter, your
argument boils down to "nice car, but if you remove
the engine, brakes, and body, you've got a wagon just like
everybody else, so what are you really adding?"
*boggle*

Neither. I'm not making arguments either, just
observations.

> I'm disappointed by your phrase "WSGI embraced
more openly", both generally and specifically. In
general, I'm saddened that people continue to use
"WSGI" as a buzzword to support their
architecture-du-jour. WSGI is an interface, not a component
architecture. It facilitates a wide variety of
architectures, and the constant (if recent) misapplication
of the term "WSGI" to mean "you may only
compose stacks MY way" is hurting WSGI's overall
potential. There is room enough with WSGI for monarchies,
republics, and communes. My money's not on the communes,
but neither am I up-in-arms about other people's way of
doing things. Be tolerant.

And I'm saddened that people read the WSGI spec, look at
some WSGI
code, but don't really *make* their own stack using WSGI
components so
they can get a solid feel for what its changing. It's not
just about
plugging apps into other apps, or having middleware. It goes
beyond
that.

No one using WSGI would be silly enough to say "you
may only compose
stacks MY way". Heck, the whole point of my last email
was to try and
show that people are assembling a variety of stacks because
its so easy
for *everyone* to assemble their own stack *their* way. This
is why I
continue to see more and more interest in components that
don't dictate
how your stack needs to be composed.

I should note though, that the CP approach so far is more of
the
commune approach. That is, CP is happy to try and use WSGI
to enhance
itself, but it gives nothing back outside of the CP commune.
CP has
none of its own middleware that other people using other
stacks can
plug-in. Notice that in all the talks about WSGI and CP, no
one is ever
saying, "What great thing in CP can we put into WSGI
middleware so that
everyone can use it in addition to us?". Instead its
always, "How can
we use so-and-so to help us".

I'd like to think I'm exceptionally tolerant by putting
what fits well
into WSGI middleware whenever possible, which means people
can use the
code without any other choices I've made in Pylons.

> Specifically, I understand you mean "WSGI"
in the sense of "more code in middleware, less in the
framework", but in CP's case, what could you possibly
do with a future stripped-down version of CP that you can't
do today? You want to use WSGI middleware for sessions? Go
for it. Want to use middleware for gzipping? Great! CP is
not stopping you. CherryPy doesn't need to hemorrhage code
before you can wrap it. Play nice.

Sure, but go farther and CP isn't really doing much that
most people
need to use. Request object, response system, dispatcher,
and some
filters... that's a very small amount of code and
RhubarbTart's sparse
code-base shows that off. If I use session middleware, some
caching
middleware, a object-path dispatcher and some handy
request/response
object's, what do I need CP for?

I don't mean WSGI in the sense of more code in middleware.
In some of
the stacks I've been using, I don't even know what you
would call the
"framework", or if there is one, or even any
point in having one. WSGI
components, and middleware, make the concept of a framework
somewhat
obsolete entirely.

If you can put together the objects and dispatch you want in
50 lines
of code, that works *exactly* like you want, why would you
want to use
some "framework" that you're highly unlikely to
be able to understand
the intricacies of, that does excessively more than you want
or need?

> CherryPy 3 will most likely abstract more of the basic,
reusable logic into libraries where it belongs. We'll then
decide which features work best out-of-the-box as filters,
which work best as middleware, and which work best as bare
library code, and provide wrappers for the first two. So
CherryPy WILL be broken down a bit, just not in a
"everything must be middleware" sort of way, and
not in a panic. Have patience.

The general impression I get is that despite a lot of the
talk, there's
a remarkably small amount of actual hands-on experience
building
WSGI-based stacks amongst the Cherry-Py developers. This is
usually
rather apparent in some of the odd list messages about WSGI
that
reflect notions that just don't apply with real-world WSGI
stacks.

I've only built 2 or 3 myself, the largest and most full
featured being
Pylons, while I've helped out and worked on various WSGI
middlware
thats in Paste, Beaker (session/cache middleware), and some
in Pylons.
Building what used to be called a "framework"
has become so amazingly
easy, that a lot of the hard stuff CP does, just doesn't
apply anymore.


Rather than being adversarial and trying to fight against
this, why not
whole-heartedly try it out and see how its changing things?
Spend a few
hours and make a WSGI-based 'stack' that has the parts of
CP you use,
see what components are in Paste that make it even easier,
look at some
middleware that will help out, etc.

The point I think I'm trying to make, is that its
significantly easier,
to work from a small WSGI code-base and add-on the features
that make
it comparable to CP; rather than hacking away at a huge
legacy CP
code-base to make it as agile as starting directly with WSGI
components. The result will also be cleaner, more flexible,
and more
component-driven. If you want CP 3 to be a step into the
future of
Python web development, a step like this might be necessary.

Cheers,
Ben


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

As a user, I feel this is important for me to know. The
issues being
discussed here will have an impact on the shape of CP 3
which in turn
will impact how I develop applications. I hope that this
discussion
continues to be publicly accessible somewhere.


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

I suppose I'll chime in - all the cool kids are doing it.


Ben Bangert wrote:

[liberal snipping throughout]

> I should note though, that the CP approach so far is
more of the
> commune approach. That is, CP is happy to try and use
WSGI to enhance
> itself, but it gives nothing back outside of the CP
commune. CP has
> none of its own middleware that other people using
other stacks can
> plug-in. Notice that in all the talks about WSGI and
CP, no one is ever
> saying, "What great thing in CP can we put into
WSGI middleware so that
> everyone can use it in addition to us?". Instead
its always, "How can
> we use so-and-so to help us".

That is partly a "consequence" of not being a
bleeding-edge 
no-user-base-to-worry-about non flavor-of-the-week
framework.  Since CP 
has been around for a while and has a user base to worry
about, we 
haven't been able to simply turn on a dime and become
everyones' WSGI 
dream boat.  Since Paste, Pylons and RhubarbTart are
relatively new and 
have been designed from the ground up with WSGI, they are
obviously 
going to be able to offer more in the WSGI department.

Regarding the commune idea, don't take not having our
filter code as 
middleware as not contributing to the Python web community. 
Earlier, 
you mentioned the CP WSGI server which is not bound to CP
and is 
available for reuse.  The webtest module is available for
writing unit 
tests that don't depend on CP.  Obviously, Kevin found CP
appealing 
enough to include it in TurboGears and that community has
done a great 
job using projects from across the Python world to make a
full featured 
web app framework.  And since CP applications *are* WSGI
applications, 
you get stuff like Robert's HTTPREPL, which gives you a
nice ajaxy 
Python interpreter in the browser.

I haven't been with the project from the beginning, but as
far as I 
know, CP has always tried to stay as open as possible and to
allow the 
developer to have as much freedom as they want.  By
providing a simple 
framework that tries not to make choices for you, I think
the project 
has given a lot to the Python web community, and not just
catered to a 
commune.

> The general impression I get is that despite a lot of
the talk, there's
> a remarkably small amount of actual hands-on experience
building
> WSGI-based stacks amongst the Cherry-Py developers.
This is usually
> rather apparent in some of the odd list messages about
WSGI that
> reflect notions that just don't apply with real-world
WSGI stacks.

Well, seeing that projects like Pylons and RhubarbTart are
pretty fresh 
out of the gates, I imagine that folks with lots of
WSGI-based stacks 
under their belts are hard to find.  Regarding CP, some on
the team are 
more well versed than others.  Robert has done a bunch for
CP regarding 
WSGI.  I am a relative new-comer to CP and WSGI.  Sylvain
has been 
getting into it lately.

So *if* being totally whiz-bang WSGI componentized is
essential for 
Python web frameworks (I said framework, ah!), then maybe we
have some 
catching up to do.  But when it comes to creating a great
framework (I 
said it again!), the metaphorical question of the day is -
is this a 
sprint or a marathon?

> The point I think I'm trying to make, is that its
significantly easier,
> to work from a small WSGI code-base and add-on the
features that make
> it comparable to CP; rather than hacking away at a huge
legacy CP
> code-base to make it as agile as starting directly with
WSGI
> components. The result will also be cleaner, more
flexible, and more
> component-driven. If you want CP 3 to be a step into
the future of
> Python web development, a step like this might be
necessary.

*sigh* CP isn't huge.  At least it has never felt that way
to me.  As 
far as the light-weight name drop, RhubarbTart, it's built
on Paste, 
right?  Doesn't that have to be taken into account?  I
know, that could 
digress into "well, CherryPy is built using the xzy
module".  My point 
being, what RhubartTart does is simple and it is cool.  But
a lot of 
other complexity likely lies beneath.

As Robert already mentioned, we are certainly going to
componentize what 
needs componentizing in CP3.  And middleware - sure,
probably.  But I 
guess since Pylons and RhubarbTart will rule the galaxy by
then, what's 
the point? 

Long live Python, long live CP,

Christian
http://www.dowski.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
-~----------~----~----~----~------~----~------~--~---

> pardon the intrusion, but what does this have to do
with cherrypy users?
>
>
I think this does is important for CP end users to
understand how our 
choices are decided or not.
Sorry if this discussion sounds a bit too religious though
:(

- Sylvain

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hello Ben;

>
> And I'm saddened that people read the WSGI spec, look
at some WSGI
> code, but don't really *make* their own stack using
WSGI components so
> they can get a solid feel for what its changing. It's
not just about
> plugging apps into other apps, or having middleware. It
goes beyond
> that.
>
> No one using WSGI would be silly enough to say
"you may only compose
> stacks MY way". Heck, the whole point of my last
email was to try and
> show that people are assembling a variety of stacks
because its so easy
> for *everyone* to assemble their own stack *their* way.
This is why I
> continue to see more and more interest in components
that don't dictate
> how your stack needs to be composed.
>   

But WSGI does dictate it though due to its interface. As
simple as it 
is, you are still obliged to follow it.

> I should note though, that the CP approach so far is
more of the
> commune approach. That is, CP is happy to try and use
WSGI to enhance
> itself, but it gives nothing back outside of the CP
commune. CP has
> none of its own middleware that other people using
other stacks can
> plug-in. Notice that in all the talks about WSGI and
CP, no one is ever
> saying, "What great thing in CP can we put into
WSGI middleware so that
> everyone can use it in addition to us?". Instead
its always, "How can
> we use so-and-so to help us".
>
> I'd like to think I'm exceptionally tolerant by
putting what fits well
> into WSGI middleware whenever possible, which means
people can use the
> code without any other choices I've made in Pylons.
>
>   

That's very kind and as Christian said, CP is transparent
as well and 
all our code is available for everyone to grab and reuse. I
agree it's 
not packaged as a WSGI middleware but do not say we don't
give it back 
to the community.


>
> Sure, but go farther and CP isn't really doing much
that most people
> need to use. Request object, response system,
dispatcher, and some
> filters... that's a very small amount of code and
RhubarbTart's sparse
> code-base shows that off. If I use session middleware,
some caching
> middleware, a object-path dispatcher and some handy
request/response
> object's, what do I need CP for?
>   

This is very simplistic. Why would I need Pylons for? Why
would I need 
web.py for? etc. and yet people tend to choose different
frameworks 
because they fit their mind.

I'm being stupid again but your point is just too
simplistic IMO.


>
> Rather than being adversarial and trying to fight
against this, why not
> whole-heartedly try it out and see how its changing
things? Spend a few
> hours and make a WSGI-based 'stack' that has the
parts of CP you use,
> see what components are in Paste that make it even
easier, look at some
> middleware that will help out, etc.
>   

The fact we look defensive is because we have been repeating
for a while 
now that although we do see the value of WSGI, we will not
make CP only 
a WSGI stack. That being said we have long agreed to design
future 
version of CP well enough so that using it in a WSGI context
makes it 
more transparent for WSGI hardcore user. My problem is that
it does not 
sound enough for you and you push us to get defensive
instead of 
accepting our choices.

We want both worlds because we believe there is room for
both ways of 
doing web development in Python, with and without WSGI.

What more do you need?

We look bad ad I really don't appreciate that as we have
proved our will 
to improve the situation.

As Christian said, sure some CP devs are more keen to WSGI
and some less 
but in the end we have said we would design CP to make sure
it plays 
even nicer with WSGI. I believe it is a good decision.

Maybe your best options would be to follow the development
of CP3 and 
help us in the WSGI department to make sure it is well
designed. That 
would be much more productive for everyone.

- Sylvain

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---