Two great posts from Christian

"Remi Delon" <remicherrypy.org> writes:

> Hello everyone,
> 
> Note that we've also been working on a new
documentation system (one
> of the weakest points of CP right now ;) ) that will be
live this
> week-end.

Perfect, I can't wait.

Jason

--~--~---------~--~----~------------~-------~--~----~
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  wish knew more, so I can understand how this is an
improvement. I
been working with CP for a while now and know what it can
do, I just
have no idea how the internal stuff works, rather than I
know address
get mapped to objects and callables and stuff. If you guys
dont mind
can you explain in simple terms how this is an improvement
?. Pretty
please, i crave to know more.!


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

On 3/9/06, gogomongmail.com <gogomongmail.com> wrote:
>
> I  wish knew more, so I can understand how this is an
improvement. I
> been working with CP for a while now and know what it
can do, I just
> have no idea how the internal stuff works, rather than
I know address
> get mapped to objects and callables and stuff. If you
guys dont mind
> can you explain in simple terms how this is an
improvement ?. Pretty
> please, i crave to know more.!

This is, I think, part of the reason that Ian Bicking has
had trouble
selling Paste. Describing this stuff to someone who's not
doing a web
framework has sometimes seemed to be difficult.

The next major TurboGears release is entirely based on
making good use
of WSGI. Here are the real-world benefits:

1) Application composition: imagine that you've written a
CherryPy
blog and a separate CherryPy wiki. These changes will let
you attach
both the blog and the wiki to a single site and even do some
interesting cross-app integration.

2) Nifty "middleware": a couple months ago, Ian
Bicking did a
screencast of his "eval exception" package. That
package would trap an
exception (during development) and let you evaluate
expressions on the
server side in the context of the exception to help you
figure out
what went wrong. Very nifty. WSGI middleware is similar to
CherryPy
filters, but a bit lower level and applied a bit
differently.

3) including other apps - as Christian points out, you can
toss a
MoinMoin into your app if you wish, even though it has
nothing to do
with CherryPy! You have more ability to build up an entire
site in
Python without worrying as much about how each part is
implemented.

4) code sharing among frameworks - this is the least
tangible one for
end users, but the results can still be impressive. The
middleware is
applicable to any web framework that uses WSGI. Each server
doesn't
*have* to implement their own session handling or caching or
exception
handling or transaction handling. If a component is designed
to work
within the WSGI realm, the possibiltiy to reuse it between
frameworks
is much greater. Ultimately, this should result in better
software,
because there are more people looking at a single bit of
code.

Kevin

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

Kevin Dangoor wrote:
> The next major TurboGears release is entirely based on
making good use
> of WSGI. Here are the real-world benefits:
>
> 1) Application composition: imagine that you've
written a CherryPy
> blog and a separate CherryPy wiki. These changes will
let you attach
> both the blog and the wiki to a single site and even do
some
> interesting cross-app integration.
>
> 2) Nifty "middleware": a couple months ago,
Ian Bicking did a
> screencast of his "eval exception" package.
That package would trap an
> exception (during development) and let you evaluate
expressions on the
> server side in the context of the exception to help you
figure out
> what went wrong. Very nifty. WSGI middleware is similar
to CherryPy
> filters, but a bit lower level and applied a bit
differently.
>
> 3) including other apps - as Christian points out, you
can toss a
> MoinMoin into your app if you wish, even though it has
nothing to do
> with CherryPy! You have more ability to build up an
entire site in
> Python without worrying as much about how each part is
implemented.
>
> 4) code sharing among frameworks - this is the least
tangible one for
> end users, but the results can still be impressive. The
middleware is
> applicable to any web framework that uses WSGI. Each
server doesn't
> *have* to implement their own session handling or
caching or exception
> handling or transaction handling. If a component is
designed to work
> within the WSGI realm, the possibiltiy to reuse it
between frameworks
> is much greater. Ultimately, this should result in
better software,
> because there are more people looking at a single bit
of code.

This is a nice summary, Kevin.  I think it should be worked
in, with
Christian's posts and more into an executive summary of
WSGI^H^H^H^HPortable Web components for CherryPy.  As I've
been
stressing on #cherrypy IRC I think there is a lot of
confusion among
users, and that this doesn't help meet anyone's goals.  As
an example,
I think it needs to be made crystal clear somewhere that
WSGI != Paste,
preferably with an overview of of what optional things Paste
builds on
top of WSGI.  My sense as an observer is that CherryPy will
move to
embrace WSGI, but not necessarily Paste, and someone should
be as clear
as possible as to the reasons.

And for you, Keven, it would be very valuable to get your
perspective
in trems of TurboGears direction.  You say "The next
major TurboGears
release is entirely based on making good use of WSGI."
 Are you already
sold on Paste as the basis for this?  Either way, how does
that affect
your view of CherryPy as the server framework for TG?  If
you really
are more interested in WSGI than full on paste, what are the
remaining
pain points you're aware of in using WSGI with CherryPy? 
Does
Christian's wsgi_filter make a difference?  Please forgive
me if some
of these questions are inane.  I'm pretty much trying to
represent the
confusion of the typical user.  I've spent some time trying
to
understand this whole CherryPy/WSGI/Paste SOAP Opera, and
I'm lost, so
I can imagine how others feel.  I think clear communication
of
motivations, goals and resolutions will really help everyone
avoid
duplication of work, impenetrable arguments and even
bewildering forks.
 Robert suggested a wIki for the discussion.  Sounds good to
me.

But in the meantime, do you have any bananas of further
illumination to
share?

Thanks much.

--
Uche Ogbuji                               Fourthought, Inc.
http://uche.ogbuji.net 
                  http://fourthought.com
http://copia.ogbuji.net  
                http://4Suite.org
Articles: http://uche
.ogbuji.net/tech/publications/


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

On 3/10/06, Uche Ogbuji <uche.ogbujigmail.com> wrote:
> And for you, Keven, it would be very valuable to get
your perspective
> in trems of TurboGears direction.  You say "The
next major TurboGears
> release is entirely based on making good use of
WSGI."  Are you already
> sold on Paste as the basis for this?  Either way, how
does that affect
> your view of CherryPy as the server framework for TG? 
If you really
> are more interested in WSGI than full on paste, what
are the remaining
> pain points you're aware of in using WSGI with
CherryPy?  Does
> Christian's wsgi_filter make a difference?  Please
forgive me if some
> of these questions are inane.

These questions aren't inane at all.

My perspective always starts with the user (in this case, a
developer
using TurboGears). I really wanted TurboGears 0.8 to allow
you to take
multiple TurboGears apps and join them together in a site.
That didn't
quite work out. A whole bunch of other stuff came up for
0.9, but I've
always had this in the back of my mind.

I also understand that sometimes you really want to combine
things at
deployment time in a config file, rather than in a Python
file. I have
additionally recognized some use cases for which something
like Routes
works better than CherryPy's dispatch (a great example of
this is
backwards compatibility with existing URLs).

Either way, I've wanted for people to be able to download
and install
a blog, for instance, and have it running trivially on their
site
alongside the rest of their code.

Since TG 0.8, I've also seen interesting WSGI middleware
cropping up
from time to time, like Ian's evalexception. I only expect
that to
increase.

So, the above couple of paragraphs really summarize what
I'm after for
that next major release of TG (codename "First
Class"). My goal is to
get these things in the quickest and cleanest way possible.
It pays to
not get too attached to a given piece of code, because that
can
sometimes be blinding when a better alternative comes along.

I'm not 100% fond of the syntax, but PasteDeploy's config
files are
very powerful ways to hook things up. And the syntax can be
smoothed
over. So, I do expect PasteDeploy to be involved. First
Class already
adds a tg-admin serve command that fires up a server based
on a
configuration. That will almost certainly remain in First
Class. But,
there's no reason that CP's WSGI server can't be handling
the requests
in that command!

I'm also leaning toward a name-based config rather than a
path-based
config. The idea is that you can give applications and
controllers
names and refer to them by those names in the config file.
Those apps
can then be attached to whichever URLs you need. While this
is
different from CherryPy's configuration, I don't think
it's
incompatible. Doing a translation from name to path
shouldn't be too
difficult. (TurboGears would likely be doing
cherrypy.tree.mount()s
behind the scenes on behalf of the user.)

The thing that is a question is whether CherryPy does the
dispatch to
a method or RhubarbTart does. There are plusses and minuses
on both
sides (isn't that always the way of it?). Right now, First
Class uses
RhubarbTart, because that enabled the
"Python-style" of application
embedding. Christian's wsgi_filter may do that as well,
though.

Right now, there's no final answer on what does the
dispatch in TG First Class.

Kevin

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

Thank you I can see how this would be a great improvement.
So far the
applications I have been working on are very simple and only
run on the
desktop, I have 1 that I'm about to complete and 1 still on
the drawing
board. This would be a great way to build big applications
by building
small parts first and then glueing all together. Thanks for
the
explanation.


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

There's a post not mentioned here, also by Christian that I
think
really illustrates a key thing WSGI is bringing about, and
Paste
somewhat capitalizes on.

The need for something like CherryPy is not what it used to
be.
Consider this great summary of where cherrypy is mentioned:

CherryPy currently stands on its own as a robust, simple,
doesn't-make-decisions-for-you web framework. It provides a
Pythonic
way to write applications that utilize HTTP. It is also a
key part in
the TurboGears framework (for now, at least). It is
approaching a
stable 2.2 release.

>From Christians post:
http://blog.dowski.com/2006/03/28/ye-olde-future-of
-cherrypy/

Now, given how WSGI makes it easy to write web applications
on a very
low level, and its rather easy to write basic object
abstractions on
top (like a request API object, response object, etc.). What
else do
you need? A dispatcher? Plug one in, there's Routes, and
RhubarbTart
implemented a object-path dispatch similar to CP's.

If filters are dropped, and WSGI is embraced more openly in
CherryPy,
CherryPy itself is essentially destroying that which makes
it *not*
WSGI. In the end, what will be left is a light layer on top
of WSGI
that isn't as clean as something designed as such, since CP
has a whole
bunch of stuff in it thats essentially pre-WSGI legacy
stuff.

As RhubarbTart demonstrates, you can have a simple, light
layer on top
of WSGI, thats as minimal as possible, and as powerful as
possible
without a lot of work or code.

Where does this leave CherryPy and frameworks in general?
That's a
great question that I think we're just going to have to
find out.
Pylons and RhubarbTart are the first, and there's many,
many little
frameworks popping up. Most of the time people don't even
bother
releasing them, they're so trivial to make.

I've had more than a dozen emails from people using Routes
to dispatch
in their own little WSGI-based frameworks that they created
solely for
their applications. The WSGI components out there continue
to lower the
bar... until soon even complete novices will be able to put
together
exactly what they want. Since these parts can very concise
and
contained, I'd consider them more reliable, robust, and
easier to have
comprehensive unit tests. How can a hulking, hard-to-test,
less
flexible 'framework' compete with that?

Personally, I think CherryPy is for the most part obsolete
in the face
of WSGI driven web development. I know other people who are
into WSGI
have said similar things, though not out in the open.
Hopefully I won't
catch too much flak for what a bunch of people have known
for awhile.

Pylons is merely a configuration of WSGI parts. TurboGears
FirstClass
looks like it will be the same thing, with a slightly
different
configuration. It's quite likely a good amount of those
WSGI parts will
be the same code and packages.

PasteDeploy isn't necessary to deploy an app using other
Paste parts.
You can in just a few lines of Python code start-up a WSGI
app using
Paste parts just like you can start up a Cherry-Py server.

There's a lot of great code in CherryPy, the CP WSGI server
is very
fast, and I'm sure there's a bunch of other stuff I'm not
aware of as
well. These are the things CP should harp more on, and I'd
like to hear
more about them so I know what CP is adding that WSGI + a
few objects
and a dispatcher don't give me.

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

Oops, need to clarify one point, Pylons and RT aren't the
first. That's
prolly Wareweb or one of Ian's creations. 


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

Hi Ben,

Before that my message gets wrongly interpreted I would like
to say that 
even though I have not produced any code WSGI-compliant yet
I have 
indeed read carefully the PEP333 and see how a few web
frameworks such 
as Pylons use it.

WSGI is a very nice interface that has a great potential and
it is true 
that today it is impossible to avoid it. That being said
WSGI also has 
unanswered questions because it has not really been used in
large 
production or pushed to its limits AFAIK.

Many people keep talking about the "plugability"
brought by WSGI 
middleware and applications.

Well WSGI has a couple of issues on this one that I would be
happy if 
anyone could clarify.

1. Imagine I write a self-contained WSGI application using a
couple of 
middlewares I made on my own. Say for example a gzip filter
and one that 
changes the Content-Type based on content negotiation with
the UA (eg. 
returning application/xhtml+xml when supported). Now imagine
I release 
my application as a bundle so that users could simply drop
it on their 
server (this is basically what many people have marketed
about until 
now). But wait, due to the design of their server, they
might already 
have several middlewares running just on top of their
servers because 
they want to ensure that they only serve text/html or they
do a 
different kind of compression by default which is not gzip.
Well you 
will tell me they can simply configure my application so
that they get 
rid of my middlewares right. True indeed, but then whose to
say my 
application will work the same? Can you ensure that? Well
you could come 
back to me and check it out. Everything is possible right...
I'm being 
stupid here I know but the point is the whole 
WSGI-plug-it-in-as-you-wish will lead to issues that might
be minors but 
could also be more annoying and I find a bit strange no one
raises those 
potential issues. Pluggability is never that transparent.

2. Another point that worries me regarding PEP 333 is that
it leaves 
many decisions unreplied. Things such as:

"""Applying these principles to a variety
of HTTP features, it should be 
clear that a server *may* handle cache validation via the
If-None-Match 
and If-Modified-Since request headers and the Last-Modified
and ETag 
response headers. However, it is not required to do this,
and the 
application *should* perform its own cache validation if it
wants to 
support that feature, since the server/gateway is not
required to do 
such validation."""

Well there is something annoying here as it means an
application 
developer which needs HTTP caching on will need to add it by
default to 
its application as it won't be sure the underlying HTTP
WSGI server will 
support it. So much for less duplication of code... Besides
how is an 
HTTP server supposed to make good HTTP caching as it has no
knowledge of 
the application it serves? It will be a very basic caching
and won't 
really match the needs of the WSGI app.

Besides, even if you do caching as a middleware, you may
decide that for 
some parts of the application that middleware has to be the
first one to 
be reached by the request, but some other time you may
decide it not to 
be the first one. I don't find middleware that flexible in
that case.

3. The "Buffering and Streaming" section of the
PEP is also confusing to 
me has it says that application and middleware should never
wait for 
content to be produced and returned ASAP, if no content is
available 
then they must return an empty string which the server will
serve 
immediatly. However if the HTTP server uses
Transfer-Encoding: Chunked, 
it will have to serve an empty string with a Content-Length
of 0 which 
is a flag indicating the end of the chunked data and would
confuse the 
UA. That also means that the server will be limited in it
chunked data 
length to whatever the application/middlewares can provide
when it 
should not be that way as the server is the only responsible
for such 
choices. My understanding of that chapter might be entirely
wrong but 
even after reading it many times, I find it confusing to the
least.

These were just a few points that poped into my head while
thinking of 
WSGI because we have met such issues with CherryPy design as
well and 
which are not easily solved.

You say that CherryPy is becoming obsolete in regards of the
power of 
WSGI. In many ways you are right and I am not surprised WSGI
has gained 
such support among the community. However does it mean we
have to stop 
being different? Are we doing this to rule the world of
Python Web 
Framework? Maybe the real challenge for CP today is to
follow the path 
it has taken so far and still be enjoyable as a
self-contained, pythonic 
HTTP toolkit. CP has lots of changes to face of course but
it does not 
mean WSGI is the unique path to follow.

Again this might sound as someone who is against WSGI when I
am really 
not. However, I acknowledge the fact things have worked so
far without 
WSGI and that there are many people who don't care at all
about being 
able to plug other pieces of software to their application.
In that case 
they can choose between a WSGI aware framework or not. As
long as they 
get productive with any I don't see anything wrong, do you?

If every framework out there goes WSGI, there will be a
dozen ones doing 
the same work the same way which will lead of course to a
point where  
there will be the need for only one WSGI framework and no
more. Why 
would someone would write a library such as Paste again when
it is 
already done? What would someone write a new web framework
again when 
Pylons already exists? Maybe the fact the Python Web Dev has
evolved so 
much in last couple of years is actually because people have
done things 
differently so that users could simply choose what suit them
best. 
Django is not better than TG but you would not make a DJango
user at 
ease with TG design and vice versa. WSGI is technically a
nice interface 
but forgets about the people using it IMO. For instance I am
a big fan 
of Amara, the Python library for XML made by Uche, but I'm
not fan of 
ElementTree. I don't say the first one is better per se but
simply that 
the way it is design is more natural to me. Should I drop
Amara simply 
because ElementTree becomes part of the Python stdlib? I
don't think so.

Anyway, many people have had a go at the CP dev in the last
few months 
because we haven't embraced WSGI as of yet and we have not
really always 
been very clear in our message (uche reminded me that point
recently 
;)). Ego and communication issues I guess :(

This is normal that users would like to keep CP while being
also 
attracted to WSGI; as a CP dev there are many little ideas I
appreciate 
in WSGI. I believe that even though our current
implementation looks 
like a hack it is still feasible to use WSGI in CP as
Christian has 
shown. However, I also believe some developers would like
their little 
pet being used in a wider audience such as the one brought
by TurboGears 
and WSGI is the key to that.

CP 3.0 is about to start and many things should change and
it is quite 
clear that WSGI will be much more present in our heads from
the start so 
it is likely to have a better support for it in CP 3.
Nonetheless I 
think it is also important to say that we also want to make
CP works as 
it has always worked without WSGI. Then we would make
everyone happy ;)

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

Sylvain Hellegouarch wrote:
> WSGI is a very nice interface that has a great
potential and it is true
> that today it is impossible to avoid it. That being
said WSGI also has
> unanswered questions because it has not really been
used in large
> production or pushed to its limits AFAIK.

Several rather large production applications have been
deployed using
WSGI, its such a minimal interface that there's generally
little
overhead.

> Well WSGI has a couple of issues on this one that I
would be happy if
> anyone could clarify.

Sure, I'll see if I can answer some of these.

> 1. Imagine I write a self-contained WSGI application
using a couple of
> middlewares I made on my own. Say for example a gzip
filter and one that
> changes the Content-Type based on content negotiation
with the UA (eg.
> returning application/xhtml+xml when supported). Now
imagine I release
> my application as a bundle so that users could simply
drop it on their
> server (this is basically what many people have
marketed about until
> now). But wait, due to the design of their server, they
might already
> have several middlewares running just on top of their
servers because
> they want to ensure that they only serve text/html or
they do a
> different kind of compression by default which is not
gzip. Well you
> will tell me they can simply configure my application
so that they get
> rid of my middlewares right. True indeed, but then
whose to say my
> application will work the same? Can you ensure that?
Well you could come
> back to me and check it out. Everything is possible
right... I'm being
> stupid here I know but the point is the whole
> WSGI-plug-it-in-as-you-wish will lead to issues that
might be minors but
> could also be more annoying and I find a bit strange no
one raises those
> potential issues. Pluggability is never that
transparent.

Indeed. First, this is one of the reasons that the PEP
actually says
middleware should never alter the transfer-encoding. While
I've seen
several gzip middleware's out there, the WSGI PEP actually
outlaws
these (the end of the content-length section):
http://www.python.org/dev/peps/pep-03
33/#handling-the-content-length-header

Pluggability of applications is not guaranteed by WSGI, but
its much
easier to have pluggable WSGI applications as a result.
Plugabbility of
WSGI middleware is more of the plug-it-in-as-you-wish
because
middleware by its nature is intended to be mostly ambivilant
of what
happens up or down the middleware stack.

There's always ways for an application to be screwed up by
the person
using it, or ways for someone to make an application in an
inflexible
manner. WSGI doesn't change that. Well designed
applications using WSGI
will be easier to plug-in without worrying much about other
middleware
causing problems.

When plugging in a WSGI app, you will always need to take a
look at
what the app does, and how, to ensure that your middleware
doesn't
screw it up. Middleware should not be blindly transforming
the
content-type of all data returned into xhtml, there's a
dozen different
problems with middleware like that.

> 2. Another point that worries me regarding PEP 333 is
that it leaves
> many decisions unreplied. Things such as:
>
> """Applying these principles to a
variety of HTTP features, it should be
> clear that a server *may* handle cache validation via
the If-None-Match
> and If-Modified-Since request headers and the
Last-Modified and ETag
> response headers. However, it is not required to do
this, and the
> application *should* perform its own cache validation
if it wants to
> support that feature, since the server/gateway is not
required to do
> such validation."""
>
> Well there is something annoying here as it means an
application
> developer which needs HTTP caching on will need to add
it by default to
> its application as it won't be sure the underlying
HTTP WSGI server will
> support it. So much for less duplication of code...
Besides how is an
> HTTP server supposed to make good HTTP caching as it
has no knowledge of
> the application it serves? It will be a very basic
caching and won't
> really match the needs of the WSGI app.

I don't see what the problem is here, it reads rather
clearly to me.
The WSGI server doesn't need to 'support' those features
since you can
get the HTTP headers yourself in your WSGI app, and send out
your own
headers.

What that section is saying is that your application should
be doing
the caching checks, not the server, and that you shouldn't
rely on the
server/gateway to be doing caching checks. So if you want to
use those
HTTP caching features, do it in your WSGI application,
don't rely on
the server/gateway doing it.

> Besides, even if you do caching as a middleware, you
may decide that for
> some parts of the application that middleware has to be
the first one to
> be reached by the request, but some other time you may
decide it not to
> be the first one. I don't find middleware that
flexible in that case.

You probably wouldn't want middleware to do the HTTP
caching unless
there was some way your app could inform the middleware of
when it
should let your app respond vs when it should reply with a
304 message.

> 3. The "Buffering and Streaming" section of
the PEP is also confusing to
> me has it says that application and middleware should
never wait for
> content to be produced and returned ASAP, if no content
is available
> then they must return an empty string which the server
will serve
> immediatly. However if the HTTP server uses
Transfer-Encoding: Chunked,
> it will have to serve an empty string with a
Content-Length of 0 which
> is a flag indicating the end of the chunked data and
would confuse the
> UA. That also means that the server will be limited in
it chunked data
> length to whatever the application/middlewares can
provide when it
> should not be that way as the server is the only
responsible for such
> choices. My understanding of that chapter might be
entirely wrong but
> even after reading it many times, I find it confusing
to the least.

I unfortunately don't know enough about this scenario to
comment much
on it. If you asked on the Web-SIG list, I'm sure someone
who's worked
on this case would be able to supply a more useful reply.

> You say that CherryPy is becoming obsolete in regards
of the power of
> WSGI. In many ways you are right and I am not surprised
WSGI has gained
> such support among the community. However does it mean
we have to stop
> being different? Are we doing this to rule the world of
Python Web
> Framework? Maybe the real challenge for CP today is to
follow the path
> it has taken so far and still be enjoyable as a
self-contained, pythonic
> HTTP toolkit. CP has lots of changes to face of course
but it does not
> mean WSGI is the unique path to follow.

No, I don't think it does mean that. However, since there
are
super-flexible frameworks built with WSGI from scratch, it
means that
its significantly less likely someone desiring flexibility
and a simple
WSGI environment would want to use CherryPy. Mainly because
CherryPy is
embracing WSGI, while the other frameworks were built with
it.

At that point, rather than emphasizing that CP plays well
with WSGI, it
will be more important to emphasize what CP is handling that
the other
WSGI-based framework is not.

> Again this might sound as someone who is against WSGI
when I am really
> not. However, I acknowledge the fact things have worked
so far without
> WSGI and that there are many people who don't care at
all about being
> able to plug other pieces of software to their
application. In that case
> they can choose between a WSGI aware framework or not.
As long as they
> get productive with any I don't see anything wrong, do
you?

Not at all. The fact that more and more powerful WSGI
components are
coming out would to me indicate that its more likely
they'll be more
productive using a WSGI-based framework. This isn't the
case now for
everything, there is no WSGI-based framework that can toss
up an Admin
interface quite like Django for example.

Again, noting the difference between CP and wsgi-based
stacks becomes
an important differentiator.

> If every framework out there goes WSGI, there will be a
dozen ones doing
> the same work the same way which will lead of course to
a point where
> there will be the need for only one WSGI framework and
no more.

I doubt it. If someone wants the same exact way to do
something as a
framework provides, they'll use that framework.

> Why
> would someone would write a library such as Paste again
when it is
> already done?

They probably wouldn't. They'd use Paste WSGI components
instead of
writing their own or if they wrote a better version those of
us using
the Paste component could easily switch to the better one.

> What would someone write a new web framework again when
> Pylons already exists?

If they wanted something that operated in a very different
manner,
they'd either tweak Pylons to provide that, or write their
own stack
that works exactly how they like. If they write their own,
its still
quite likely however that they would use similar components
to build it
so that they can save time.

> Maybe the fact the Python Web Dev has evolved so
> much in last couple of years is actually because people
have done things
> differently so that users could simply choose what suit
them best.
> Django is not better than TG but you would not make a
DJango user at
> ease with TG design and vice versa. WSGI is technically
a nice interface
> but forgets about the people using it IMO. For instance
I am a big fan
> of Amara, the Python library for XML made by Uche, but
I'm not fan of
> ElementTree. I don't say the first one is better per
se but simply that
> the way it is design is more natural to me. Should I
drop Amara simply
> because ElementTree becomes part of the Python stdlib?
I don't think so.

I think there's a better way to explain where WSGI fits
into this.
Consider the Python standard library. Imagine that when
using the
Python standard library, you were forced to *only* use
modules from it.
If you want to use other modules, you had to use other
people
libraries, at which point you could only use modules they
supplied.

This resulted in everyone rewriting the same code, because
you couldn't
share individual modules. Until WSGI, this scenario is how
web
development with Python was for the most part. WSGI lets you
share
individual modules without being forced into the entire
library.

You can use the best session middleware/module you like, or
the best
request object API, etc. You can use the dispatcher that
meets your
needs perfectly. This is where WSGI is truly useful and
powerful, not
merely pluggability of WSGI applications, but re-usability
of
individual components that make up traditional non-WSGI
frameworks.

Because of WSGI, you can pick and choose each part you want
and make
your own framework very easily. Just like when making any
Python app,
you can import whatever modules you want from any package
you want that
gets your job done. If you don't want to hunt down the best
parts to
make up your stack, you can choose from pre-assembled ones.
This is
what Pylons and RhubarbTart are. It's what TurboGears
First-Class will
be.

As I mentioned before, its quite likely there'll be many of
the same
exact components used between these three and more.
Extremely useful
middleware that fits in with the design of each framework
will likely
be in each one, as its so easy to add them.

> This is normal that users would like to keep CP while
being also
> attracted to WSGI; as a CP dev there are many little
ideas I appreciate
> in WSGI. I believe that even though our current
implementation looks
> like a hack it is still feasible to use WSGI in CP as
Christian has
> shown. However, I also believe some developers would
like their little
> pet being used in a wider audience such as the one
brought by TurboGears
> and WSGI is the key to that.

Yes, this is also a big appeal to making solid WSGI
components. If I
make a really good session middleware, besides for having it
used in
Pylons, it can easily be used in RhubarbTart or TurboGears
FirstClass,
or dozens of other little frameworks people create for
themselves.

Competition is fundamentally different because of WSGI.
Pylons and
RhubarbTart don't compete, they use many of the same parts
in a
different configuration. They can both easily survive and
get upgrades
as long as the parts they use get upgraded, and since those
parts have
a broader audience there's more feedback, bug fixes,
updates, etc.

Competition is no longer at the 'framework' level, but its
at the WSGI
component level. The best session middleware will be used by
everyone,
the best caching system, etc. I have heard people say on
many occasion
about Framework X, "Yes, I really like how it does
this and that, but
unfortunately it can't do other-thing nearly as well as
Framework Z."
With those parts using WSGI middleware or components made
for re-use
between WSGI stacks, you can have exactly what you want.

There won't be a single WSGI framework, because given the
various
choices at all the different levels, there's hundreds or
thousands of
possible combinations. Instead there will likely be a few
best of breed
session layers, or a few best of breed dispatchers (that
handle the
styles that most people like).

> CP 3.0 is about to start and many things should change
and it is quite
> clear that WSGI will be much more present in our heads
from the start so
> it is likely to have a better support for it in CP 3.
Nonetheless I
> think it is also important to say that we also want to
make CP works as
> it has always worked without WSGI. Then we would make
everyone happy ;)

Yes, the question is, what will using CP 3.0 give you, that
your own
WSGI-based framework that does *exactly* what you want
won't give you?
If you make a little WSGI based framework, can you use
anything from CP
3.0?

Why not make the best parts of CP 3.0 into WSGI components,
and have CP
3.0 be a default configuration of those parts? This way
regardless of
whether people want the whole CP 3.0 setup, they can still
use parts
that are excellent regardless of their framework. If CP 3.0
is going to
be thinking more about WSGI, it should also think about what
it brings
to the WSGI world. If parts are usable without the whole,
there's more
opportunity to lure people into the entire setup as well,
while still
giving them flexibility to use as much or as little as they
want.

Really, what'd help the most, is if the CP developers sat
down, and
made a small framework from scratch with WSGI and some
middleware. Ian
Bicking has a how-to on making a small framework which is a
good
starting point. That way rather than thinking about the WSGI
PEP, the
real-world uses and applications of the PEP would become
obvious.

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