On CherryPy, WSGI, paste, multiple applications and deployment
re...@cherrypy.org
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]:
> It's not like this is Paste-specific stuff. No one knows how to
> do this stuff in CherryPy. No one seems to have any authoritative
> answer on how you deploy these apps -- how you move between
> servers, how you change the application root, how you put apps
> together into a single server. Everything is ad hoc stuff that just
> barely works for one app on one server. It's all "recipes"
> No one knows how to do this stuff in CherryPy
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.
> I think these shaky underpinnings are risky for the project.
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.
Armin Ronacher
> 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*
Sylvain Hellegouarch
>
> Ok. So CherryPy has died for me.
I am sorry to hear that.
> 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.
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.
> All my respect applies to Ian Bicking for working hard of making
> CherryPy WSGI compatible. *thumbs-up*
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
Armin Ronacher
> 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.
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.
> > All my respect applies to Ian Bicking for working hard of making
> > CherryPy WSGI compatible. *thumbs-up*
>
> 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.
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
Robert Brewer
> Ok. So CherryPy has died for me. That's not only ignorance,
> PEP and should work for CP also.
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.
> Nobody has advantages of a broken WSGI Interface.
We all agree on that.
Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org
re...@cherrypy.org
> view of one developer.
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.
> All my respect applies to Ian Bicking for working hard of making
> CherryPy WSGI compatible. *thumbs-up*
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.
Ian Bicking
> Which leads me to:
>
> [ from http://blog.ianbicking.org/my-cherrypy-rant.html]:
> > It's not like this is Paste-specific stuff. No one knows how to
> > do this stuff in CherryPy. No one seems to have any authoritative
> > answer on how you deploy these apps -- how you move between
> > servers, how you change the application root, how you put apps
> > together into a single server. Everything is ad hoc stuff that just
> > barely works for one app on one server. It's all "recipes"
>
> > No one knows how to do this stuff in CherryPy
>
> 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 ...
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.
winstonwolff
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
______________________________________________________
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
Istvan Albert
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:
> "Of course, all this can be done and lots of people have done it, but it's ad hoc."
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.
Olivier Favre-Simon
"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.
Titus Brown
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
Titus Brown
-> 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
Kevin Dangoor
> 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.
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
Istvan Albert
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:
Istvan Albert
> let them take advantage of it.
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?
Remi Delon
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.
christian
> Well, looks like I've started my first flamewar :)
> That was certainly not my intention ...
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.
> 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.
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.
> So what have we gained:
> - the code can now be shared by other frameworks
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.
> What have we lost:
> - we've added another layer and therefore more complexity and another
> dependency
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.
> - 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).
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.
> 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).
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.
> 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).
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
Ben Bangert
> 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.
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.
> 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.
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.
> So what have we gained:
> - the code can now be shared by other frameworks
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.
> What have we lost:
> - we've added another layer and therefore more complexity and another
> dependency
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.
> - we've taken away some freedom from the framework (WSGI imposes some
> rules on the underlying framework)
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.
> - 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).
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
Sylvain Hellegouarch
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 :
Titus Brown
->
-> 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
Kevin Dangoor
> Well, looks like I've started my first flamewar :)
> That was certainly not my intention ...
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.
> 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.
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.
> 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).
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.
> 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).
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.
> 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).
That's actually better than a compromise. Everyone can use CherryPy in
the way they see fit.
Kevin
Kevin Dangoor
>
> I think this is an endless discussion and we are not going anywhere.
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.
> 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.
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
Ian Bicking
> 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.
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.
> 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.
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.
> 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
WSGI does not imply any dependencies. WSGI is a protocol, not a
library. CherryPy can implement perfect WSGI without adding any
dependencies.
> - we've taken away some freedom from the framework (WSGI imposes some
> rules on the underlying framework)
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.
> - 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).
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.
Sylvain Hellegouarch
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 :
Ian Bicking
> 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 :)
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.
> 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.
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.
> 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.
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 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.
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.
Remi Delon
>> 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.
>
> 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.
You're mixing "full-stack" frameworks, such as TurboGears and "low-level"
frameworks such as CherryPy. Both clearly correspond to different needs. I
just meant that ideally there should be at least one framework in each
category that is good enough.
Yes, CherryPy is in the "low-level" category and it will stay there.
>> 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
>
> WSGI does not imply any dependencies. WSGI is a protocol, not a
> library.
I was talking about the scenario where people would use CherryPy with Paste.
Then it does add dependencies.
> CherryPy can implement perfect WSGI without adding any
> dependencies.
>
>> - we've taken away some freedom from the framework (WSGI imposes some
>> rules on the underlying framework)
>
> 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.
I'm not sure about this but from what I understand, people won't be able to
do "cherrypy.root = HelloWorld()" anymore if we want to make CherryPy 100%
WSGI compliant (because "root" needs to be "app-specific" and not global)
I never claimed that these were not possible with Paste, I claim that Paste
doesn't add that much value because they:
- either are already in CherryPy (test framework, authentication, static
files, multi-app (CP2.2),
- either are pretty useless (CGI ... I did write an experimental CGI filter
for CP at some point but dropped it because I didn't see the point)
- either don't belong to CP (annotating middleware, although I'm just
taking a guess because I have no idea what the heck an "annotating
middleware" is)
- either could easily be added to CP and we'll probably do it if we feel
like it's worth it (interactive debugger)
Just one more point and then I'll shut up :) :
Right now, Paste is the only "WSGI middleware" out there ... From what the
python community has shown in the past (people like to have fun and to share
the result of their fun) I wouldn't be surprised if people started to write
"competitors" to Paste ... Next thing you know users will be asking "should
I use CherryPy with Paste, Quixote with Poste, or Twisted.web with Puste"
(mix&match and repeat...) Great :(
Anyway, as I've said in my previous post, we *will* perfect our WSGI support
(let's not forget that it's already quite good). Now I'm off to preparing
the 2.2-beta release ...
Remi.
Ben Bangert
> I was talking about the scenario where people would use CherryPy with Paste.
> Then it does add dependencies.
Then those people would be adding the dependency, not CherryPy. Whether
that means TurboGears requiring Paste, etc. Either way, making CherryPy
both WSGI compatible and Paste 'compatible' does not mean you have to
require or depend on Paste.
> I'm not sure about this but from what I understand, people won't be able to
> do "cherrypy.root = HelloWorld()" anymore if we want to make CherryPy 100%
> WSGI compliant (because "root" needs to be "app-specific" and not global)
Sure they can, and Ian's CherryPaste lets you do this still. It
substitutes in a cherrypy object that works a little differently
though.
> I never claimed that these were not possible with Paste, I claim that Paste
> doesn't add that much value because they:
> - either are already in CherryPy (test framework, authentication, static
> files, multi-app (CP2.2),
Regarding multi-app, thats only if you use solely CherryPy. Go tell the
user that wants to use a excellent blog app written in Framework A, and
a great forum app written in Framework B, that they should go rewrite
one of them. Paste compatibility means you don't have to tell them
this.
Of course everyone is happy to say, just use MyProject, don't touch
anything using OtherCompetingProjects, and you'll be ok. Django apps
are pluggable... into other Django apps. Now CherryPy apps can work
with CherryPy apps in CP2.2. Paste compatibility means you can use
multiple applications without caring what Framework they were written
in.
Does CherryPy do OpenID authentication? It's in paste.auth middleware,
any WSGI compliant framework can use it (even without the rest of paste
if you wanted).
> - either could easily be added to CP and we'll probably do it if we feel
> like it's worth it (interactive debugger)
Why waste the time re-implementing it, when its already made in a
framework-neutral way?
> Right now, Paste is the only "WSGI middleware" out there ... From what the
> python community has shown in the past (people like to have fun and to share
> the result of their fun) I wouldn't be surprised if people started to write
> "competitors" to Paste ... Next thing you know users will be asking "should
> I use CherryPy with Paste, Quixote with Poste, or Twisted.web with Puste"
> (mix&match and repeat...) Great :(
WSGI middleware doesn't really invite competition, because its so
framework neutral there's no point re-implementing bits of it. The
other thing is the fact that since it is WSGI middleware, if someone
else made "competing" parts, you'd be able to seamlessly plug them in,
because its WSGI middleware.... again, the concept of competition is a
little different at this level.
> Anyway, as I've said in my previous post, we *will* perfect our WSGI support
> (let's not forget that it's already quite good). Now I'm off to preparing
> the 2.2-beta release ...
Excellent.
- Ben
Brian Beck
developed at least a dozen CherryPy applications, and now I'm starting
to build things with Pylons due to "the Paste issue." I'm willing to
forego CherryPy's simplicity and use a package that's still incurring
breaking changes weekly; willing to use a set of tools at which I am a
novice (I would claim to be nearly expert at the TurboGears suite of
tools); this all should say a LOT about what my priorities are, and I
don't think I'm alone. Believe me, everyone posting here *wants* to
use CherryPy for the reasons that make it great, but the cases Ian
brings up are not contrived.
In the cases where I've had to deploy CherryPy in a reasonably
real-world environment (this mostly means have to get along with an
already existing web server), I ran into the same problems as everyone
else.
--
Brian Beck
Adventurer of the First Order
Sylvain Hellegouarch
> Regarding multi-app, thats only if you use solely CherryPy. Go tell the
> user that wants to use a excellent blog app written in Framework A, and
> a great forum app written in Framework B, that they should go rewrite
> one of them. Paste compatibility means you don't have to tell them
> this.
Of course that does sound interesting but I feel it is a bit catchy as
well to pretend it will be that easy even with paste. Users will have
anyway to learn how both frameworks work in a way or in the other which
means more hassle and less fun. There is also problems with potential
version conflict. Say Framework A uses lib 1a and framework B uses lib
1b which are not necessarily compatible, I wouldn't know if that's paste
role to manage that or if the user would have to handle it. In such case
what is the benefit?
Again, we all agree on the fact deployement is a pain and a solution
such as Paste could save a lot of hassle. However I'm just afraid its
assumption about the environment are slightly simplified.
But you know, I won't deny if I'm wrong, I might as well realise it one
day and be a happy Paste use myself :)
>
> Of course everyone is happy to say, just use MyProject, don't touch
> anything using OtherCompetingProjects, and you'll be ok. Django apps
> are pluggable... into other Django apps. Now CherryPy apps can work
> with CherryPy apps in CP2.2. Paste compatibility means you can use
> multiple applications without caring what Framework they were written
> in.
On the paper... let's wait for real case example to say that.
>
> Does CherryPy do OpenID authentication? It's in paste.auth middleware,
> any WSGI compliant framework can use it (even without the rest of paste
> if you wanted).
Does B has C? Does A has T? What is the point? CherryPy is not a
framework but a simple Python wrapper around HTTP. That is pretty much
all it is. CherryPy had rfc 2617 auth before paste even existed... so what?
Regarding the fact, paste.auth is neutral, I enjoy that idea and I'll
look at it but CherryPy works in a given way that I'm not sure
paste.auth will support nicely. I will actually look into it asap.
> Why waste the time re-implementing it, when its already made in a
> framework-neutral way?
>
>
> WSGI middleware doesn't really invite competition, because its so
> framework neutral there's no point re-implementing bits of it.
Django people might argue there was no point in re-implementing a web
framework when they had theirs... Stating what you say assumes paste
will be troubleless for users. I'd like to remind you that paste is not
really spreaded yet. Lots of CP issues were found only because TG has
been so spreaded and people started doing stuff the early CP users
didn't think of.
The
> other thing is the fact that since it is WSGI middleware, if someone
> else made "competing" parts, you'd be able to seamlessly plug them in,
> because its WSGI middleware.... again, the concept of competition is a
> little different at this level.
Well I sure hope so but then we ought to ask to PJB to clean up the
specification to avoid corner cases and ghost meanings otherwise it
won't happen.
- Sylvain
Ian Bicking
> > Regarding multi-app, thats only if you use solely CherryPy. Go tell the
> > user that wants to use a excellent blog app written in Framework A, and
> > a great forum app written in Framework B, that they should go rewrite
> > one of them. Paste compatibility means you don't have to tell them
> > this.
>
> Of course that does sound interesting but I feel it is a bit catchy as
> well to pretend it will be that easy even with paste. Users will have
> anyway to learn how both frameworks work in a way or in the other which
> means more hassle and less fun.
There is an education aspect. But everything new requires people to
learn new things. I hope that it will be more a change in perspective
than a bunch of new information you have to know. More about styles of
practice; the sort of thing best learned from example. Like MVC. But
learning by example can be hard until there is a chunk of people to
learn from.
That said, I put multiple applications in the same process frequently,
and it works fine. I personally am not a representative programmer, to
be sure, but it can be done, and it has not been a source of great
problems. One of my motivations is to avoid hard problems -- both
debugging and design problems -- more than avoid new concepts. That
said, the techniques used are not high-concept or particularly
abstract. But my perception has been that something needs to click for
a person for them to see it as straight-forward and easy, and until
then it can be hard to understand what's going on. Or maybe hard to
understand what the point is at all. I get a lot of that, and honestly
I still don't know how to describe Paste to people.
> There is also problems with potential
> version conflict. Say Framework A uses lib 1a and framework B uses lib
> 1b which are not necessarily compatible, I wouldn't know if that's paste
> role to manage that or if the user would have to handle it. In such case
> what is the benefit?
There's no resolution for that, or any forseeable resolution. The best
we can do is spawn a subprocess. That said, I think there is potential
to make that kind of spawning process easy and make it require very
little configuration. I haven't run into this issue yet.
> > WSGI middleware doesn't really invite competition, because its so
> > framework neutral there's no point re-implementing bits of it.
>
> Django people might argue there was no point in re-implementing a web
> framework when they had theirs... Stating what you say assumes paste
> will be troubleless for users. I'd like to remind you that paste is not
> really spreaded yet. Lots of CP issues were found only because TG has
> been so spreaded and people started doing stuff the early CP users
> didn't think of.
There's definitely challenges and rough spots and things yet to be
figured out. But the best way to figure those things out is to dive
in, see what works by trying to do it. The basic technology works;
WSGI can be used this way. The first time I deployed the same
application with two configurations in the same process, it just worked
(somewhat to my surprise). I find that when I put the interactive
debugger in front of applications, it just works. One of the great
things about working off a well-defined spec is that new combinations
really *can* just work.
That said, the education aspect is significant. We as a community need
to figure out a lot of things. Lots of dumb little things, like where
and how to list links to dependencies, or what order the installation
process should work in, or any number of details.
Ian
Rubic
> perfect our WSGI support
Hi Remi.
I'm a bit late to this discussion, but I'd like
to share a use case why WSGI is important for my
applications.
Our apps must be secured with SSL. Conventionally,
every SSL website must have a unique ip address
and use the assigned TCP port 443 -- i.e. each of
my secure web applications would require a unique
external ip address.
However with Twisted (unlike Apache) it's actually
possible to have named virtual hosting behind an
SSL certificate. So I now have a twisted server
handling requests to TurboGear/CherryPy applications
running on the same domain (thanks to Matt Goodall):
https://app1.server.domain.com/
https://app2.server.domain.com/
Perhaps this is too elaborate example to be used
as an argument to push WSGI into CherryPy, but I'm
grateful that I can have these two disparate pieces
working together.
---
harpethbikeclub.com: satisfied user of python-hosting.com
for the past couple of years ;-)
re...@cherrypy.org
> every SSL website must have a unique ip address
> and use the assigned TCP port 443 -- i.e. each of
> my secure web applications would require a unique
> external ip address.
Well, AFAIK you only require a unique IP address if you want to use
different certificates for each site. This is because the SSL protocol
in itself doesn't include the Host header so the server can't know
which certificate to use ...
More info on this page:
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html (look for "Why is it
not possible to use Name-Based Virtual Hosting to identify different
SSL virtual hosts?")
> However with Twisted (unlike Apache) it's actually
> possible to have named virtual hosting behind an
> SSL certificate.
Is it really possible to use a different certificates for each site ?
If yes I wonder how they have accomplished that... If not then it's
just the same as Apache (ie: it's possible but you have to use the same
certificate).
> harpethbikeclub.com: satisfied user of python-hosting.com
> for the past couple of years ;-)
Glad to hear that :)
Remi.
Rubic
> address if you want to use different
> certificates for each site.
We're using a wildcard certificate, but that's
not the issue from my understanding of the
topic. The people who've assisted me are better
versed in the details.
The problem, as your link above points out, is
that the request header cannot be read by the
server before the SSL handshake is finished.
One possible solution would be to use different
ports for each SSL host, but in the real world
the only acceptable port is 443.
Our twisted hack doesn't rely on the Apache
server reading the headers, so we bypass the
problem. I'll probably put up a wiki description
with the details. I'm pretty happy (and amazed)
so far.
Tamas Hegedus
I would like to daemonize my cherrypy application.
It works well without deamonization and with 'nohup'.
If I try the double-forking magic
(http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012) my
cherypy application does not.
The double-forking code works for a simple application like writing data
in every second to a file.
How would you daemonize a cherrypy application?
At this moment I would like to use it as a stand alone web-application,
but later on I am planning to put behind apache...
Thanks for your suggestions,
Tamas
--
Tamas Hegedus, PhD | phone: (1) 919-966 0329
UNC - Biochem & Biophys | fax: (1) 919-966 5178
5007A Thurston-Bowles Bldg | mailto:heg...@med.unc.edu
Chapel Hill, NC, 27599-7248 | http://biohegedus.org