This is an answer to http://www.cherrypy.org/ticket/444 and
http://blog.ianbicking.org/my-cherrypy-rant.html

CherryPy was created a long time before WSGI came along. WSGI support
for CherryPy was only added later on and it's probably not perfect
right now because CherryPy was not designed with WSGI in mind.
We will try to address these issues in CP3 but right now, we don't want
to spend too much time on this in CP2 ... Why ? Because we've all got
limited time to work on CherryPy and it all comes down to priorities
...
And right now I'm more interested in fixing the security flaw in the
static filter (done), the sessiondeadlock bug (done) and shipping
CP-2.2 (beta version coming soon) rather than changing CP to make it
100% WSGI compatible. I think that these fixes and shipping CP-2.2 add
much more value.
As you've probably guessed by now I'm not a big WSGI fan because it
doesn't allow us to do anything useful that wasn't possible before and
it doesn't help solving the real life cases (more details below).

Which leads me to:

[ from http://blog.ianbicking.org/my-cherrypy-rant.html]:

Well, I've been developing, deploying and maintaining CP apps for
several years now. I've got apps using various python and CP versions,
I've got sites mixing CP and PHP apps, I've got a CP app load-balanced
on 4 servers and I regularly push new versions of the app to these
servers. And all of this doesn't seem all that hard to me and I don't
need paste or WSGI to do it ...

For instance, for deploying my app on 4 load-balanced servers and
pushing new versions regularly, I just check out the SVN tree
containing the source code of the app to each server. When I want to
push a new version to production I just run "svn update" on each of the
server (I've got a 4-line script that does the "svn update" on each
server for me). Can Paste make this process easier ? I doubt it ...
This is just one way of deploying an app ... I've also been in the
situation where we needed a more formal process (with official releases
of the app) because the app was shipped to customers ... It happened to
be on Windows so we were putting python, CP and the app in one .exe
(using py2exe) and packaging everything in an installer with InnoSetup.
The installer was just installing the app as a Windows service and it
worked great. Again, all it took was a script to do all of that and I
don't think that WSGI and Paste would have helped.

For mixing multiple apps in one website, the method I use is Apache and
mod_rewrite ... WSGI and Paste can help me mix, say, a CP app and a
Twisted app in one website but in practice, I'm much more likely to mix
a CP app with a PHP app (PHPBB for instance) and in that case, WSGI and
Paste can't help ... I'm a big fan of Apache (or lighttpd) in front of
CherryPy with mod_rewrite ... You really get the best of both worlds
and Apache is probably faster and more powerful (you can use all the
mod_xxx modules, starting with mod_ssl) than any WSGI server will ever
be.

For running multiple instances of the same app, all I do is run "python
app.py -c xxx.cfg" multiple times. I just need one copy of "app.py" and
I just have one config file per instance I want to run ...

For "mounting" multiple instances of one app within one CP server, the
simple method I've been using so far is this: the constructor of the
app takes as a parameter the path where it is mounted ("mount_path").
Whenever it generates an absolute URL is prefixes it with "mount_path".
Doesn't seem that hard to me:

class Blog:
    def __init__(self, mount_path):
        self.mount_path = mount_path
    def index(self):
        return 'blah blah ... <a href="%s/foo">foo</a>' %
self.mount_path
    def foo(self):
        ....

cherrypy.root.blog1 = Blog1('/blog1')
cherrypy.root.blog2 = Blog1('/blog2')

Note that this process will now be officialized with the new
"cherrypy.tree.mount" API in CP-2.2.

Well, I don't share your negative view on this and I'd rather have a
more positive approach and look at what makes CP so great.
CP is easy, lightweight and has a very pythonic API. That's why people
like it and write web apps with it and they don't need WSGI or Paste to
do it.

So, in short:
 - I'm not going to spend too much time on WSGI and Paste myself
because I don't really believe in it and I've got more useful changes
to make to CherryPy.
 - Having said that, I acknowledge the fact that some people might see
some added value in WSGI and Paste ... this is open-source ... everyone
has some features that they're personnally interested in ... submit
patches for your pet features and we'll include them.

Remi.

Ok. So CherryPy has died for me. That's not only ignorance, that is the
view of one developer. And WSGI is defined in a PEP and should work for
CP also. Nobody has advantages of a broken WSGI Interface.

All my respect applies to Ian Bicking for working hard of making
CherryPy WSGI compatible. *thumbs-up*

Hi Armin,

I am sorry to hear that.

You are right but interesingly I wonder if there so many web frameworks that
actually support entirely correctly WSGI. If they exist, then great :)

BTW, there is hardly one HTTP server outthere that does respect entirely HTTP
RFCs but the web hasn't crashed yet. So although I agree we should (we must)
have a better WSGI support (I like standards) let's not shoot down CherryPy
because of that.

I think you should thank Robert instead since he is the one who has made
CherryPy what it is now. He has brought support to WSGI long before Ian tried.
I am happy Ian revealed some flaws we hadn't thought so far but again we have
agreed on bringing a better support in CherryPy 3.

- Sylvain

Hi Sylvain,
I for my self like WSGI. My applications run von FastCGI, CGI,
mod_python and other
interfaces and I don't have to think about interface specific features,
the Wrapper
handles that for me.
And WSGI (especially paste) will be the only way to let hosters support
python on
a webspace. Nobody would allow a user the edit the apache config.

Maybe I will then CherryPy works together with WSGI. But for now I will
use my own
wrapper for the next webapplications and django for my community page.

Regards,
Armin

Simply saying, "WSGI is defined," isn't enough. Ian is not the final
authority on interpreting that spec, and it is my assertion that Ian's
interpretation of the WSGI spec is incorrect. Here's what I believe his
assertion is (corrections by Ian most welcome):

Given:
    SCRIPT_NAME: The initial portion of the request URL's
    "path" that corresponds to the application object,
    so that the application knows its virtual "location".

The phrase "so that ... knows" means that the application side MUST NOT
otherwise know its virtual "location"; it MUST only obtain that
information from the value of SCRIPT_NAME.

My assertion is:

The phrase "so that ... knows" means "so that the application MAY know".

Some "applications" may be that stupid; lots of CGI scripts were written
that way (and then each rolled their own hacks to get around IIS' or
Apache's quirks). CherryPy, however, is more self-aware than that, and
expects the deployer to tell CherryPy the virtual "location" of apps on
server start. Support for accurate SCRIPT_NAME values in current WSGI
servers and gateways continues to be spotty and untrustable; CherryPy
avoids that issue by being more aware.

I am the first to admit that "telling CherryPy the location of your app
on server start" is not as flexible as it could be in CP 2.1. We are
working on a much-improved API for 2.2. But that is an entirely separate
issue and has nothing to do with CP's WSGI support.

We all agree on that.

Robert Brewer
System Architect
Amor Ministries
fuman...@amor.org

Yes, that is my view and I have the right to express it :)
I think that WSGI adds almost no value. If the goal is to be able to
deploy a CherryPy application under FastCgi or CGI (for practical
hosting purposes) then it's much easier to just write a small custom
wrapper for CherryPy. This is pretty easy and Quixote had it way before
WSGI came along.
I think that WSGI just adds another layer that complicates things,
confuses people and brings very little benefit for real life cases.

But I do realize that this is only my view and CP is not a one-man
project ... This is why we'll try to improve our WSGI support in CP-3.

I respect Ian for his work but I disagree with the message that he's
been spreading lately on various blogs and forums.
I get the feeling that he's spreading the following message (Ian,
please correct me if that is not the message that you're spreading):

a- Deploying a CP app is hard
b- Paste is the answer and therefore people should use Paste.

I disagree with both. I don't think that deploying a CP app is hard at
all (I've explained some of the techniques I use in my previous post).
And I don't think that people need Paste. It just complicates things,
adds another layer, another dependency and confuses people. In some
limited cases it might be useful but for most real life cases I think
it doesn't help at all (again, I've explained in my previous post why
in most cases Apache (or lighttpd) is the answer, not Paste).

Remi.

It is my perception that it *is* hard for most people, and that there's
no clear and consistent way to handle this sort of thing.  Of course
you can figure this stuff out, because you have a fairly complete and
internalized view of how CherryPy works from the inside and you
understand the problems you encounter, but it's not clear to other
people, and from what I can tell any such deployment depends on several
pieces being configured in tandem with confusing failure cases and lots
of potentials for subtle bugs in deployment.

Maybe a more explicit critique: there is no single, consistent story
for how someone should lay out and write a CherryPy application and
deploy it in multiple environments (obviously at least devel and
production), under different base paths (e.g., / in devel with custom
HTTP server, and /myapp in production under Apache), and how to manage
a set of such applications that form a typical website.

Of course, all this can be done and lots of people have done it, but
it's ad hoc.  Many of the recipes bouncing around are broken
(VirtualPathFilter on the wiki is broken, for instance).  The solution
isn't to fix the recipes; this should be core functionality.

When tree.mount was discussed on IRC, I asked that people step back and
consider how people were supposed to use this.  But no one replied or
reacted to that at all.  That feature isn't being *designed* the right
way.  Figure out how people are should ideally use CherryPy for the
variety of likely use cases.  Then make that work.  Instead these
deployment issues are being designed backwards, starting from the
object publisher and then just hoping that people will figure out how
to use those functions in their applications.  If I understood how
people were going to use tree.mount, for instance, I could possibly
implement another version of Tree that does what I want.  But since I
have no idea what is expected, I have no idea when or how that is going
to be called, and I can't reliably do anything with that API.

But, back to the concrete, you say you want CP3 to address some of
these issues.  So what will CP3 look like?

Also, I hope you'll understand my rant for what it is -- an emotional
response to frustration I felt after struggling with the code (which is
why I called it a rant).  If it pisses y'all off and you go off saying
"I'll show him", then okay.  So show me.  If I just steamed in private,
dismissed CP in private conversations, dismissed the projects that
build on CP, I don't think that would be much better.  But if you don't
think my criticism is based on anything, and you plan to simply ignore
it, then I suppose it serves no purpose to say it publically.  Except
perhaps to make it clear to people who are interested in Paste that CP2
isn't a good choice (which I am saying here because that's basically
what you are saying).

Also note that I wouldn't have any opinion on any of this if I wasn't
trying to reach out to you guys, making a genuine effort to support CP
as a whole in Paste.

I agree with Remi that WSGI complicates things while adding little  
value.  CherryPy is so great for me because it is so simple to  
understand.  It does just one thing--pass HTTP requests to methods  
and returns back HTML.  All the other stuff that Django and  
TurboGears adds on is good if you need it, but if you don't, then you  
pay the price of a larger learning curve.  I haven't looked into  
Paste, but it sounds like it is for a situation where you have a  
bunch of web apps that you want to work together.  That's not what  
CherryPy is about--CherryPy is about making the smallest simplest web  
app.  And because it does that so well, it's the foundation of these  
other projects.  That's exactly right--keep CherryPy simple, and then  
build other projects around it for more specialized situations.

As far as deploying, CherryPy was much simpler to deploy than Webware.

-winston

On Jan 23, 2006, at 2:04 PM, r...@cherrypy.org wrote:

______________________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com
learning by creating - video game courses for kids in new york

______________________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com
learning by creating - video game courses for kids in new york

My feelings are similar.

That is to say that I feel little enthusiasm towards all this talk
about 'proper' WSGI support and/or Paste. I just don't think that it is
possible to have a solution that is both generic and simple ... in
practice things just do not work that way ...

For me cherrypy is about "invisibility", it completely stays out of the
way. It is already such an amazingly simple and straightforward
approach that all these 'generalizations' appear to be solutions to
problems that do not actually exist.

To address a sentence in a post above:

I would not be so quick to equate 'ad-hoc' with 'bad' . Practicality
beats purity, simplicity beats standardization. I'd rather do whatever
needs to be done in  few lines within a simple framework rather than
through yet another abstract and layer introducing yet another set of
limitations.

i.

If one thinks about WSGI being only apps, then the obvious conclusion is
"CP already does this".

Sure Remi fixing filters (BTW thank you Remi) was top priority from his
point of view, which is CP developer's one.

But the whole point IMHO of WSGI is **middleware** . May be there
wouldn't have been needed fixes in the first place if filters (static,
session, auth, etc) were pulled from a central repository (setuptools
eggs, PasteDeploy) where they would be developed/fixed once for all, as
shared components between frameworks.

One of the few Python drawbacks is that such a powerful and expressive
language makes it easy (compared to say C or even Java/C#) to ever
rewrite stuff. So we get CP sessions, flup sessions, XYZ sessions, etc.

"Apache load balancing amongst multiple hosts" and "multiple CP
processes per host" are all great stuff, but that's orthogonal to the
"multiple apps per process" and "apps being agnostic about their actual
location/mount point" issues.

Saying "I want my very own filters for my framework" is like saying "I
want my own mod_cache/rewrite/ssl"... Sure you can do it, but is this
the best possible decision ?

So I disagree about "WSGI brings nothing". May be nothing completely
new, but smarter and much more open design for sure.

A legitimate point of worrying is overhead. I'm not sure of anything
here, but I don't see any reason for the WSGI adapter being that bad
against say SCGI or FCGI or mod_python. May be some tests (e.g. ab2
stats about CP+CherryPaste vs. genuine CP) would enlighten this...

Another one is "WSGI is sometimes ambiguous". Right... but I don't think
that's a blocker... Often RFC's are very very open about "important"
stuff, but the web is functional today.

The IRC log show that most of the issues are well-known (and that smart
people do not get angry even when strongly disagreeing on some
"important" subject), so

Sure this is all free software... so Remi (and from what I understand
Robert, Sylvain and the other devs) have all rights to say "not for me"
or "not before CP3".

Most projects where feedback of the majority of end-users is blindly
ignored by developers are doomed.

I'm still wondering about what percentage of CP users do want/need WSGI,
and I'm very interested in other users feedback...

I've been great CP fan, and I almost instantly dropped Webware when I
discovered CP. Now I'm looking about Pylons+Mighty because of the Paste
issue, even at the cost of learning another (perlish ;-) templating
language...

This is too bad, when compared to other projects...

e.g. TurboGears & templates:

At start the official point of view was "Kid templating is the best,
don't tell us about the other packages"...

Then open-minded people did understand that whatever the reason, other
guys may hate XML stuff, or simply have tons of existing templates.

So Christian Wyglendowski and Cliff Wells designed a Template Plugin
engine and spec, moreover a framework agnostic one.

And K.Dangoor did accept to push it in TG even if he's still a great
defender or Kid.

And B.Bangert integrated Buffet support in Pylons for guys that don't
want to depend of Myghty only.

That's free software, too ;-)

I can admit that WSGI/Paste support will not show up before CP3... Then
let's hope CP3 is not that far.

signature.asc < 1K Download

Hi guys,

on this "WSGI brings nothing" -- a few points.

1. I wrote some testing infrastructure that is *completely generic* to
        any WSGI app.  (wsgi_intercept)

        Took me more than an hour to get it working with CherryPy, and
        even then I had to check with the list to make sure I wasn't
        overlooking something dumb, since I'm not a CP expert.

        I think this is an obvious, tangible situtation where a clean,
        documented WSGI interface (without side effects) is valuable.
        It allows people to build tools that are generic to any one of
        the bajillion Web frameworks.

2. I maintain that any properly architected application can be separated
        out into a completely WSGI compliant app quickly and easily.

        Inability to cleanly separate HTTP handling from request
        handling -- which is all that any Web framework needs to
        be WSGI-capable -- is a sign of a badly thought out
        architecture that will affect more than just the WSGI interface.

        I don't know if this is a problem that CP has.  If it doesn't,
        then make it WSGI compliant.  If it does, then admit it and
        move on ;).

        Just for comparison, I wrote WSGI adapters for Quixote and SCGI
        in less than an hour or two.  I'm not a genius, but Quixote and
        SCGI were written by smart people and it was very easy to pull
        out the necessary components.

3. It's stupid to argue against standardization at the level of HTTP
        request munging.  It benefits virtually everyone, and it makes
        it trivial to plug & play in a variety of situations.

        How can any of these be bad?

Take Ian's rant as a rant, learn -- or not -- from it, and move on.  But
every argument about how WSGI compliancy is useless, or benefits no-one,
or is the wrong shade of plaid, is missing the point.

cheers,
--titus

-> That is to say that I feel little enthusiasm towards all this talk
-> about 'proper' WSGI support and/or Paste. I just don't think that it is
-> possible to have a solution that is both generic and simple ... in
-> practice things just do not work that way ...

I'm curious -- if you've read the WSGI PEP, what's not generic and
what's not simple?

cheers,
--titus

On 1/23/06, r...@cherrypy.org <r...@cherrypy.org> wrote:

Consider it like this: the Python standard library already supports
XML. Why does it need ElementTree? Because if there's a higher-level
XML API that's part of the standard library, people will use it and
get more done faster.

I view the idea behind WSGI and Paste's usage of it similarly. The
idea is to make the API for web app frameworks higher level, promoting
more reuse. All app frameworks do sessions in one form or another.
It's not much of a differentiaor (though some certainly have better
implementations than others). Moving that stuff into common code will
ultimately make the tools better.

There will never be agreement on application coding style. That will
always be unique from framework to framework... but stuff that *can*
reasonably be pulled out and shared can only be shared if there are
common interfaces people are writing to. And that's where WSGI and
Paste come in.

I think the potential for Paste is greater than the reality today.
But, the potential won't be reached unless people are using tools that
let them take advantage of it.

Kevin

I can answer that with a question myself, is WSGI is so generic and so
simple, how come one needs Paste, (yet another generic and simple
pradigm set)  to make it work as intended?

I'd rather subscribe to the "Say No to the Frankweb" ideology:

http://blogs.law.harvard.edu/ivan/2005/07/12#a9

I think this is really the pitfall here, because the direct translation
is this:

  - if everyone else will (re)write their stuff to obey a certain
standard... there is potential for some good things to happen ... well
yeah hypotetically it could be true but is that realistic to expect?

Well, looks like I've started my first flamewar :)
That was certainly not my intention ...

The way I see it is that WSGI is the wrong answer to a problem that
shouldn't be there in the first place: Python has too many web frameworks
that are not good enough. If they were good enough then people would just
choose one that they like and it would do everything they need. Therefore
they wouldn't care about other frameworks and WSGI.

By introducting WSGI we're just adding another layer. If you start adding
features like session handling, static data serving, caching, ... in the
"WSGI middleware" layer, you're basically moving the code from CherryPy (or
some other framework) out of CherryPy and up in the other layer.

So what have we gained:
  - the code can now be shared by other frameworks
What have we lost:
  - we've added another layer and therefore more complexity and another
dependency
  - we've taken away some freedom from the framework (WSGI imposes some
rules on the underlying framework)
  - we've taken away some power from the framework (for instance, right now
in CP you can send raw data on the socket if you want to. I'm not sure if
that's still feasible if you go through WSGI).

It is my opinion that the drawbacks outweigh the benefits. I think that a
better way to fix the "Python has too many web frameworks that are not good
enough" problem is to keep improving a framework (CP in my case) and make it
good enough so that people can just use this and don't have to care about
WSGI (this is already the case).

But this is a matter of taste and some people might think that the "code
sharing" argument is more important. We don't have to agree and that's OK
because there is a compromise ... We'll do our best to provide the WSGI
support that WSGI people need but we'll make sure that CP continues to be CP
(in particular, it'll keep the simple/pythonic API that it has).

Remi.

I don't know if it has reached that point ... yet :)  And if it
happens, I don't think it's due to any of your posts.

In theory, I can see how WSGI and middleware could simplify stuff.  But
when you start piecing (pasting? ;) together all sorts of different
parts, I think the complexity goes up and the simplicity fades.

Thankfully this can also happen without WSGI or Paste - TurboGears,
Pylons and CherryPy (using my Buffet filter) can all use a bunch of
common template plugins.  CherryPy can already use a ton of code from
other projects.  I think someone even integrated Routes with CP a while
back.

Ugh.  You know what I hate?  Tracking down dependencies, downloading 4
packages to make the one I want to use work.  I absolutely love the
fact that CP doesn't depend on anything but the standard library.
Install Python.  Install CP.  Make web app.

The setuptools package and easy_install is working towards mitigating
the dependency issue, and while I have gotten some value from it
lately, it sure is a moving target right now.  I hope it stabilizes and
makes it into the stdlib, because as of right now it is another
dependency itself.

I vote yes for keeping CP as flexible as possible.  I love writing
python code that then runs on a web app.  I also think I like that CP
doesn't define what a web app is.

Bam.  I like that paragraph so much, I think I'll put it on a tshirt.
I didn't care about writing web sites/apps in Python until I found CP
2.0 beta.  In times BC (Before CherryPy ;) I would simply write stuff
in PHP because it was easier than fitting my square mind in some Python
framework's tetrahegon shaped hole.  CherryPy is truly a Pythonic web
framework - I write Python code that makes web pages.

I think code sharing is great.  Robert Brewer's webtest and web
profiler support in CP is certainly available for other projects.  The
WSGI server that Peter Hunt wrote is there.  Just because Paste isn't
supported doesn't mean that CP and the CP devs don't play nice with
others.  Quite the contrary,  really, especially considering how open
CP is already to pretty much any available Python package (see "any
templating engine", "any persistence mechanism", etc).

Christian
http://www.dowski.com

I think that's a pretty bizarre belief. I've evaluated and tried out
quite a few of the frameworks, and talked to most of the frameworks
authors. Each framework is doing quite a bit very well, more than good
enough. Some of the design decisions that make one excellent in one
context, make it not so good in another.

While Rails gets all the hype in Ruby land, Nitro is still used by a
good amount of people. Despite the utter lack of hype, Aquarium is
running on tens of thousands of machines throughout the world as
IronPort uses it extensively. This is because it solves their unique
needs.

People do choose a framework, the fact is that people choose different
frameworks. It's smart to try and make the way the framework talks to
the server standardized, such as WSGI, so that more re-usable portions
of web tools can use this layer.

Right, what's wrong with that? Personally, I don't think its likely
session handling will work very well in purely WSGI. Some frameworks do
sessions very differently, so agreeing on a session middleware thus far
hasn't gotten far.

More importantly, you can now use other code. When you see frameworks
that more heavily leverage WSGI middleware, the benefits they gain,
maybe the importance of this will become more obvious.

The complexity can be managed and a usable way for developers to setup
middleware isn't hard. As I mentioned, the benefits are quite
compelling right now, and will only increase.

I think in this case, part of it is Paste's assumptions about the
webapps. The global problems Ian was hitting were due to some extent by
CP's assumption it'd be the only app in the process. The other issues
however were WSGI spec.

The way to fix too many frameworks is for everyone to keep improving
them all?

This is exactly the problem that brought on WSGI, everyone kept
improving their framework, and everyone had to duplicate each others
work when it came to trying to deploy an application.

I think if anything, this debate has shown that people do care about
WSGI, because they are seeing compelling reasons to use it. If you want
to harness the creative talents of more programmers, supporting WSGI
properly is in CherryPy's best interest.

- Ben

I think this is an endless discussion and we are not going anywhere.

Remi has been clear he is not keen on spending much of his time to
support WSGI because he doesn't think its value is that great. However
he hasn't forbidden anyone to spend time bringing it into CP 2.2 either
right? He is more than OK to have a very good WSGI support within CP, he
just don't want to do it himself. I think that's fair as long as he let
other people add their patches or solution (as long as they respect CP
API for now). Besides, I also think we have all in mind now that
whatever happens in CP 2, we will make sure CP 3 design can handle WSGI
natively in a proper way (the only way maybe). So as Remi said, it's a
matter of compromise.

Even if Remi sounds harsh I know for a fact he is not against WSGI at
all but he is not the one who will develop it either since he prefers
spending his energy on issues he finds more critical for now.

CP has not so many people contributing to its core right now, we all
have our life and priorities. It's just a bit frustrating on our side
that people keep pushing for it to happen when we have said many times
we would but not now. We also said that anyone could contribute.

We do listen to the community (we have shown it already in the past and
I think most people agree that we have a friendly and responsive
community), so let's not only fous on this issue to the point where
people gets angry at each other. It would be pointless.

Everyone has his taste.

- Sylvain

Ben Bangert a écrit :

-> >I'm curious -- if you've read the WSGI PEP, what's not generic and what's not simple?
->
-> I can answer that with a question myself, is WSGI is so generic and so
-> simple, how come one needs Paste, (yet another generic and simple
-> pradigm set)  to make it work as intended?

Paste is a specific implementation; WSGI is a standard.

--titus

On 1/24/06, Remi Delon <r...@cherrypy.org> wrote:

Nah... you're not going to see flames from me on this topic. (I'm not
generally one to toss out flames anyhow.)

Let me step back a bit to clarify my position in a way that was not
present in my previous message: the user comes first. (The user, in
this case, is someone who's writing a webapp.) CherryPy is great
because it's so easy and pythonic. That's why I chose it after having
tried other frameworks, and I think the API is what a lot of people
like about TurboGears. There are a lot of little things that add up to
a good experience.

Paste support is not the #1 most important thing on my list for
TurboGears. A higher priority, for example, is the ability to compose
multiple TurboGears apps together. And, as I've expressed previously,
I'd *love* for people to be able to compose apps together in the
natural python way of just instantiating the object right there in
your tree. (Yes, yes, I know there are use cases for which that's not
the best way :)

Today, I think the coolest things that a *user* gets out of Paste
would be evalexception and commentary.

Coming back to the session example from my previous message. CherryPy
has a decent session system that has had a lot of work put into it.
Other session systems have things like memcached support. Yes someone
*could* write an adapter for CP, but if that piece of infrastructure
was common then that gap in functionality would be nonexistent. This
is not something Paste has today. But, this is the kind of thing Paste
*could* have.

I will also note that Paste doesn't *have* to be the solution here,
either. The template plugins that people are using now require nothing
other than setuptools to discover and use. One could break out
components into reusable parts just using that mechanism. Paste is
another way to do it that includes a bit more higher level
configuration and its own ability to plug things together.

I'm starting to ramble so I'll get back to the point: users benefit
from using a chunk of code that is used by a larger group of people.
TurboGears could have just supported Kid intrinsically and had
secondary support for Cheetah and most people would've been happy.
Instead, by doing things a little differently, users get STAN, Myghty,
HTMLTemplate and who knows what else at the same time.

Where it gets used by more people and improved upon by more people.

As time goes on, we get used to higher and higher level interfaces.
Today, it may seem perfectly reasonable that everyone implementing a
web app framework has to implement their own session handling. Before
DBAPI, it was probably reasonable to think that everyone who wanted to
support multiple databases would have to create their own abstraction
for talking with each driver. There are countless examples of
interfaces that we now take for granted that have moved from being
something you had to worry about to something that is just part of the
infrastructure.

There are always tradeoffs. The "code can now be shared" bullet can be
split into more bullets to reflect the user impact:

- fewer bugs, caught earlier on
- more features
- more performance tuning

Having more users helps.

I do agree absolutely, though, that the common API needs to be able to
do the things you need to do. If you need to send raw data to a socket
and you can't do that with WSGI, then that's not the right solution.

This is true. And I certainly hope that users never actually care
about WSGI. But users might care about being able to use neat tools
like evalexception.

That's actually better than a compromise. Everyone can use CherryPy in
the way they see fit.

Kevin

On 1/24/06, Sylvain Hellegouarch <s...@defuze.org> wrote:

Well, my point in responding was simply to highlight what I thought
the real advantages were. Unless something new comes up, you're not
likely to hear more from me on the subject at this point. I spend too
much time doing email as it is.

I wholeheartedly agree that Remi should spend his time however he
wishes. My mesages (and others as well) were just in response to Remi
saying that there was no point to Paste. I think there is a point, but
I also think that it's not Remi's responsibility to spend time working
on a feature he has no use for.

Kevin

Conflicting messages: "just choose one", "it would do everything they
need", and an overall message that you want to keep CherryPy simple.  I
don't think this is a realistic combination of motivations.  One Giant
Stack With Everything You Need doesn't seem like a design goal for
CherryPy.  Let Everyone Program It For Themself doesn't give people the
things they need and want.

Adding another layer isn't necessarily bad, if that layer isn't a leaky
abstraction.  Part of the reason I'm being picky about WSGI compliance
is that I want to avoid that leakiness.  This doesn't have to place any
new requirements on user code, but it does relate to how the framework
invokes that code.

WSGI does not imply any dependencies.  WSGI is a protocol, not a
library.  CherryPy can implement perfect WSGI without adding any
dependencies.

I don't know of any useful freedoms that have been taken away.
Ambiguity is *not* freedom.  If there is something specific, I'd be
interested to hear it, and maybe it can be clarified or resolved.

You can't send raw data on the socket, but you can stream, and you can
push data through to the server (there's two streaming techniques in
WSGI).  WSGI is a good foundation for low-level implementations, and I
think much more reasonable than any framework for many kinds of
applications.  When you are working on the level of static file
serving, WebDAV, or some other close-to-HTTP situations, the niceties
of a higher-level framework like CherryPy just get in the way.

Anyway, there's questions about what WSGI or Paste offer for CherryPy.
So, here's a list of a few things:

* Test framework support.  Paste has a test wrapper that works on any
WSGI application.  Twill works with WSGI, and Titus has code that can
make any HTTP-based Python program use WSGI, so you can do fast
in-process testing.  zope.testbrowser will have WSGI support in the
future.  Paste's test wrapper has framework-specific hooks so you can
do full-stack testing (i.e., actually render a full page) while also
looking at intermediate values (e.g., the return value of a function).

* Paste has several pieces related to identification/authentication:
HTTP Basic, Digest, IP-based authentication, OpenID, CAS, mod_auth_tkt.
 More than one can be used in tandem.

* Debugging tools; exception reporting, including an interactive
debugger.  Validate HTML, capture print statements, profile the
request.

* Static file serving, with some support for ranges, if-modified-since,
and etags.  Serving directly from an egg using pkg_resources.

* Cascading requests through multiple applications, typically trying
each app until you don't get a 404.  This allows static and dynamic
content to share a URL space, for instance, without living in the same
directory.  There's other dispatching code as well, like an up-front
prefix-matching dispatcher that doesn't care about depth or traversal.

* CGI-calling support.  WSGI would also be a good level upon which to
write a PHP FastCGI proxy, to trully embed a PHP app in a Python app.
It would also be a good level for an HTTP proxy.  (Those last two
aren't written, but it would be great if they were, and they could be
equally useful to any Python web framework that allows reliable
embedding of WSGI applications -- and equally or more likely to come
from outside of CherryPy as inside).

* Annotating middleware is also possible, like Commentary.  Brad
Clements is writing a XSLT/TAL system as middleware, and I've seen some
other XSL projects.

Kevin,

I was not aiming at you in particular (actually you'd have been the last
person I'd have thought of anyway).

I was just talking in general regarding the topic :)

- Sylvain

Kevin Dangoor a écrit :

Note that WSGI doesn't bar any particular type of dispatching.  In
fact, I think it is very flexible about dispatching, be it through
attributes on objects, the filesystem, or configuration.

Paste could have that, but I'll also note that I'm not pushing Paste
for everything, and I haven't really pursued session support in Paste
except in a minimal way for my own uses.  I think a good reusable
session package would be neutral of WSGI, and would be interacted with
mostly as a library (that you just call into).  In turn WSGI middleware
around that library could handle some details, and I'd probably write
such a thing for my own use at least, but that would handle things like
loading the session (calling into the library), setting cookies,
ensuring finalization, and configuration.  I.e. it would only be glue.

I have tried to follow this design principle in Paste as well -- so the
exception package is a straight-forward exception formatter (you pass
in sys.exc_info()), and then there's a middleware that wraps it up for
the WSGI/web context.  Though in contrast, evalexception really is very
closely tied to the web (for obvious reasons) and isn't designed in
this way.

And again, I'm not looking for Paste to be the end-all and be-all.  I'm
happily using the template plugins myself in a project, and I wouldn't
see any reason to integrate that into Paste, nor does it bother me that
I'm using something outside of Paste.

I know Remi wasn't claiming authoritatively that this was a particular
flaw of WSGI, but I just want to reiterate lest someone read more into
this than they should, that WSGI addresses streaming well, which is
primary use case for direct socket access.  Also, WSGI does allow for
poking holes through the spec using custom environment keys, so it
really doesn't try to keep you from doing what you want to do.  I think
this fits with Python's general approach to portability -- don't cover
up the underlying system, provide higher-level constructs that are
common across platforms when possible, and since we're all consenting
adults don't stop someone from doing what they want if they feel a
compelling need to work around the system.