Google App Server makes mod_wsgi obsolete.
Graham Dumpleton
http://code.google.com/appengine/
Graham
Nimrod A. Abing
No it doesn't. You sound as if you've thrown up your arms and given up
:) I still prefer to have my projects hosted on machines that I have
total control of and I don't think my boss would consider putting his
site on a "Technology Preview". It also appears that some critical
Python modules are disabled:
http://code.google.com/appengine/kb/general.html
<blockquote>
A small percentage of native python modules, and subsets of native
python modules are not available with Google App Engine. The full list
of disabled and partially disabled Python modules can be found here.
The disabled modules fall in to the following categories:
* Libraries that maintain databases on disk are not enabled in
Python for Google App Engine
* Sockets are disabled with Google App Engine
* The system does not allow you to invoke subprocesses, as a
result some os module methods are disabled
* Threading is not available
*
* For security reasons, most C-based modules are disabled
* Other features that are limited:
o marshal is disabled
o cPickle is aliased to pickle
o System calls have been disabled
Please keep in mind that third party packages which use any of the
above features will not function with Google App Engine (packages such
as mysql, postgresql, etc).
</blockquote>
What the heck is this? Python Home Basic Edition? No thanks Google.
I'll stick to my Apache + mod_wsgi setup.
--
Best Regards,
Nimrod A. Abing
W http://arsenic.ph/
W http://preownedcar.com/
W http://preownedbike.com/
W http://abing.gotdns.com/
yml
Are you joking or are you serious with the title:
Google App Server makes mod_wsgi obsolete.
"""
unable to deploy such application locally. It seems to me that the two
approach are not really in competition but rather complementary.
Would it be possible that mod_wsgi is part of the tool chain behind
"Google Appengine" ?
Regards,
--yml
On Apr 8, 9:04 am, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
Graham Dumpleton
>
> > Google App Server makes mod_wsgi obsolete.
>
> No it doesn't. You sound as if you've thrown up your arms and given up :)
As far as future plans I had for mod_wsgi, and a new project I have
been plotting which drew on what was learnt from doing mod_wsgi, it
sort of does, at least to the degree of making one wander whether it
is worth the trouble of putting in the effort to do what I had in
mind. Have I given up, maybe not quite yet, but it is an unwelcome
development.
The buzz around Google App Server will also no doubt serve as a huge
distraction to a lot of Python people just when I thought I was
perhaps starting to get some momentum behind mod_wsgi and getting
people to understand what it does, how it works and what it could be
used for or developed into. The problem now also is that if I do ever
develop the ideas I had, I'll probably be accused of pinching them
from Google because of the overlap that exists to some degree. :-(
2008/4/8 yml <yann....@gmail.com>:
> Would it be possible that mod_wsgi is part of the tool chain behind
> "Google Appengine" ?
That is what they would call a 'pipe dream'. Google would never be
interested in mod_wsgi as they simply don't use Apache in their core
infrastructure. The only thing they run which might even remotely use
Apache is their subversion hosting services but I wouldn't be
surprised if they have a custom solution to host that as well.
Just to muddy the waters, it has been said by a few different people
at times that mod_wsgi is a Google project, is used by Google and/or
that I am paid by Google. Just to set the record straight, I have
absolutely no association with Google in that respect. The closest I
come to Google is that I use their email and discussion group
services, plus mod_wsgi is hosted on their public and free code
hosting service. The work on mod_wsgi I do, I do all in my own spare
time, my real paying job has actually nothing to do with web hosting
or writing web applications so no one pays me to do it.
Graham
Mark Rees
Do not get to depressed. I certainly know that none of the projects I have deployed on mod_wsgi could not be deployed on the Google App Engine, my clients are way to protective of their data and I need the power of SQL joins.
Mind you if I ever create the python equivalent of basecamp, I would consider Google App Engine :-)
Keep up the great work.
Mark
Nimrod A. Abing
<graham.d...@gmail.com> wrote:
>
> 2008/4/8 Nimrod A. Abing <nimrod...@gmail.com>:
>
> >
> > > Google App Server makes mod_wsgi obsolete.
> >
> > No it doesn't. You sound as if you've thrown up your arms and given up :)
>
> As far as future plans I had for mod_wsgi, and a new project I have
> been plotting which drew on what was learnt from doing mod_wsgi, it
> sort of does, at least to the degree of making one wander whether it
> is worth the trouble of putting in the effort to do what I had in
> mind. Have I given up, maybe not quite yet, but it is an unwelcome
> development.
>
> The buzz around Google App Server will also no doubt serve as a huge
> distraction to a lot of Python people just when I thought I was
> perhaps starting to get some momentum behind mod_wsgi and getting
> people to understand what it does, how it works and what it could be
> used for or developed into. The problem now also is that if I do ever
> develop the ideas I had, I'll probably be accused of pinching them
> from Google because of the overlap that exists to some degree. :-(
You might do well to publish a list of planned features if you haven't
done so already. At least you get "dibs" on thinking about it and
publishing it first :) And who ever accuses you of "pinching" them
from Google deserves to be smacked upside the head with a
clue-by-four. Clearly, people who do things such as web development in
Python will have encountered the problems that mod_wsgi attempts to
solve. It just so happens that you "got to the starting line" first
with mod_wsgi and then a 500 pound gorilla called Google steps in with
their "solution" (albeit a crippled one).
For what it's worth, the one thing that brought me to use mod_wsgi in
the first place was because I was looking for a sane way of handling
LimitRequestBody in my web app. Search the Django archives, if I
recall correctly you responded to my question and posted mod_wsgi as
part of the solution. I was using mod_python back then and I was
considering modifying it but when I tried out mod_wsgi, it made
solving the problem easier. In addition, mod_wsgi has a smaller
codebase compared to mod_python so when it comes down to
modifications, I would choose to modify mod_wsgi over mod_python any
day.
Personally I would not consider using Google App Server, not even for
my own personal projects. Like I said earlier, the Python that they
provide for you is a crippled version of the "real" thing. If you use
Google App Server:
* You don't get database libraries and you're forced to use Google's
own custom "data store". I'm sure that's OK for a college student's
web app thesis project.
* No sockets. So if your app requires IPC or XML-RPC forget it.
* No subprocess spawning. Not really limiting but there are some
things that are better handled with the fork-exec model or Unix pipes
than the standard Python facilities.
* No threading. Not that threading is any good in Python. But since
fork-exec is disabled, then your only fallback is gone as well.
* Most C-based modules are disabled for "security". Can't really blame
them since this would mean they would have to audit additional code.
In this case Google is just being lazy.
* No marshalling. WTF?!? Seriously!
* cPickle is aliased to pickle. Uhm, yeah. Like substituting molasses
for nectar.
* Syscalls are disabled, which means if your app makes heavy use of
"os" module you're screwed.
No serious developer would ever consider using something as crippled
as this. This is akin to installing Vista Home Basic on your machine
and then trying to do Systems Programming with it.
I'm sure Google App Server is there to satisfy a niche and I believe
it's there so that programmers who don't know any better will be
forced to convince their boss to pony up the big bucks for the
"Enterprise Edition".
My two cents :)
gert
seeing that gorilla on there doorstep :)
Anyway, python will be getting allot of attention in general, so you
will have the underdog alternative momentum. Also expect apache to be
in your base camp. Its going to be a ugly fight for sure. Don't forget
you know what there python weaknesses will be, so start to tackle on
that.
Nimrod A. Abing
companies out there (not just in web hosting) who have invested lots
of time in building up their infrastructure based on Apache. The LAMP
stack is so prolific and I stand by what I said earlier that Google
App Server is there to cater to a niche. I don't think that it is in
any way a direct competitor to mod_wsgi. It is Google's way of dealing
with S3 since apparently somebody has done some pretty cool voodoo and
was able to run his website using S3. See:
http://highscalability.com/google-appengine-first-look
http://blog.tomevslin.com/2008/03/amazon-s3-backs.html
Someone also has an interesting take on things:
http://staticallytyped.com/2008/04/08/googles-plans-for-app-engine/
Carl Nobile
If you are thinking that the only value of mod_wsgi is to make it easier for ISP's then maybe your right, but I see many other uses for mod_wsgi.
As I've mentioned before I'm developing an API for doing RESTful interfaces using WSGI and mod_wsgi will make it mindless to get up and running.
In other words mod_wsgi has a lot of value in the corporate world outside of ISPs.
Jez, don't give up now!!!
Carl
carl....@gmail.com
-------------------------------------------------------------------------------
gert
world on the google servers ?
Juergen Brendel
Obsolete? No way!
As far as I am concerned, mod_wsgi is THE way to run Python applications
behind Apache. Nothing else comes even close. Python is my preferred
language, and Apache is the world's preferred web-server. My
applications are not compatible with Google's infrastructure/API, nor
are they compatible with Google's business model and/or reputation.
There is a reason why Google restricts what you can do and that's why
Google might be an option for some applications, but certainly not for
all.
At the moment, if I would want to take advantage of cloud computing, I
would use Amazon EC2 to run VMs of server images, in which I have set up
Apache with mod_wsgi. That's the flexibility I need, and I think this
approach gives it to me without binding myself to Google's APIs or their
infrastructure.
Juergen
Clodoaldo
2008/4/8, Graham Dumpleton <graham.d...@gmail.com>:
>
> For anyone living in a cave:
>
> http://code.google.com/appengine/
I don't see my self writing applications that could be hostages of
Google will. I want my freedom to do whatever I want with a server.
OTOH if quality out of the box applications like forums, blogs and
wikis are ported to Google App Engine then ISPs could loose part or most of
their market. That would take sometime since the most used of them
(applications) are written in php.
Regards, Clodoaldo
Manuzhai
<graham.d...@gmail.com> wrote:
> As far as future plans I had for mod_wsgi, and a new project I have
> been plotting which drew on what was learnt from doing mod_wsgi, it
> sort of does, at least to the degree of making one wander whether it
> is worth the trouble of putting in the effort to do what I had in
> mind. Have I given up, maybe not quite yet, but it is an unwelcome
> development.
I'm not sure about this. I think what Google is doing is interesting,
but it's not something I care for myself. If you were aiming
exclusively at the PHP market (cheap, simple shared hosting), then
this will take some of the mod_wsgi mindshare. But for anyone with
larger plans, who wants to use well-tested open source software,
libraries, whatsoever, the whole GAE isn't really that interesting.
It's more like something for the Ruby on Rails fanboys than for
serious deployments of Python; which is exactly the group of users
that mod_wsgi appeals to, for being relatively easy to deploy and
powerful at the same time.
> The buzz around Google App Server will also no doubt serve as a huge
> distraction to a lot of Python people just when I thought I was
> perhaps starting to get some momentum behind mod_wsgi and getting
> people to understand what it does, how it works and what it could be
> used for or developed into.
It may serve as a distraction to some people just starting out, but
for many people who do a lot of WSGI work, I think they'll play with
GAE a bit, then move back to *real* WSGI with normal databases and the
fully available Python standard library (plus any libraries you might
want to install).
Cheers,
Dirkjan
Matti Haavikko
Did Google App Server also make Apache HTTPD and relational databases
obsolete?
No - What Google just did, they pushed the world one big step closer to
recognizing Python as ready for prime time web application development.
This is very good for mod_wsgi.
mod_wsgi is positioned to be the main winner of all this, because
(combined with e.g. Django) it is the best solution for building many
different types of systems.
- Matti Haavikko
David
Google's app engine has significantly raised the profile of Python as
a web development language for many web developers. This should
benefit all Python developers and Python-friendly web hosts.
I have been following mod_wsgi with interest, but have not used it,
because the entry cost is too steep. I am awaiting the availability
of hosts that are setup for WSGI apps in default configuration, where
I can just upload my WSGI application files and have them work, in
near-optimal fashion (memory resident, self-reloading). Google app
engine is as close to that ideal as I have found. I suspect
that many developers will jump on the Python bandwagon to use GAE, and
then graduate to private for-pay hosts in time, to use features not
available on the Google engine. If I understand mod_wsgi correctly,
it also offers a low hassle way to get WSGI apps running at
near-optimal fashion.
Graham, please put your pessimism on hold for a while, while the GAE
apps situation shakes out. If your plans included a hosting service,
please proceed. ;)
David
--
dke...@travelbyroad.net
Pitcher's Duel -> pitchersduel.python-hosting.com
Clodoaldo
>
> Hello,
>
> Did Google App Server also make Apache HTTPD and relational databases
> obsolete?
> No - What Google just did, they pushed the world one big step closer to
> recognizing Python as ready for prime time web application development.
2008/4/9, David <dvke...@gmail.com>:
>
> Matti has it right.
>
> Google's app engine has significantly raised the profile of Python as
> a web development language for many web developers.
Coincidentally my mod_python/CGI tutorial had the visits number
doubled in the last 3 days.
Regards, Clodoaldo
Graham Dumpleton
I think though it is time to put mod_python out to pasture though.
I probably should also finally unsubscribe to the mod_python mailing
list and stop answering questions about it. :-)
BTW, for mod_wsgi site statistics since July last year see attached
image. The uptake on mod_wsgi 2.0 release hasn't been too shabby
either if you look at the download page on mod_wsgi site. Compare that
to 1.3/2.0c4 and how long they took to get to the downloads they did.
Sorry for not yet responding more on this discussion, lot on my mind
right now and not much free time.
Graham
Clodoaldo
> 2008/4/10 Clodoaldo <clodoal...@gmail.com>:
>
> > 2008/4/9, Matti Haavikko <matti.h...@futurice.fi>:
> > > Hello,
> > >
> > > Did Google App Server also make Apache HTTPD and relational databases
> > > obsolete?
> > > No - What Google just did, they pushed the world one big step closer to
> > > recognizing Python as ready for prime time web application development.
> >
> > 2008/4/9, David <dvke...@gmail.com>:
> >
> > > Matti has it right.
> > >
> > > Google's app engine has significantly raised the profile of Python as
> > > a web development language for many web developers.
> >
> > Coincidentally my mod_python/CGI tutorial had the visits number
> > doubled in the last 3 days.
>
>
> I think though it is time to put mod_python out to pasture though.
You mean like taking the tutorial out from the web? Or like below just
ignoring the mailing list?
I don't think mod_python is a competitor to mod_wsgi. Typically those
trying that tutorial don't want to be forced to swallow a framework
and to make a wsgi script application work it is necessary to deal
with some things a framework developer deals with. The mod_python
publisher fits that niche. It is easy to learn and you don't feel like
pushing an elephant (a framework) into your living room.
> I probably should also finally unsubscribe to the mod_python mailing
> list and stop answering questions about it. :-)
Regards, Clodoaldo
Graham Dumpleton
>
> 2008/4/10, Graham Dumpleton <graham.d...@gmail.com>:
>
> > 2008/4/10 Clodoaldo <clodoal...@gmail.com>:
> >
> > > 2008/4/9, Matti Haavikko <matti.h...@futurice.fi>:
> > > > Hello,
> > > >
> > > > Did Google App Server also make Apache HTTPD and relational databases
> > > > obsolete?
> > > > No - What Google just did, they pushed the world one big step closer to
> > > > recognizing Python as ready for prime time web application development.
> > >
> > > 2008/4/9, David <dvke...@gmail.com>:
> > >
> > > > Matti has it right.
> > > >
> > > > Google's app engine has significantly raised the profile of Python as
> > > > a web development language for many web developers.
> > >
> > > Coincidentally my mod_python/CGI tutorial had the visits number
> > > doubled in the last 3 days.
> >
> >
> > I think though it is time to put mod_python out to pasture though.
>
> You mean like taking the tutorial out from the web? Or like below just
> ignoring the mailing list?
What I am suggesting is that mod_python is in decline and that people
should perhaps not be targeting it as a platform for application
development going forward.
A question for you so you understand what is coming. What are you
going to do with all your applications that are tied to mod_python and
cannot run on anything else, when Python 3.0 becomes main stream and
Python 2.X is seen as legacy code?
Unless some white knight comes along, I very much doubt that
mod_python will ever be ported to Python 3.0, the code base is already
somewhat unmaintainable at the C code level and working out how it
should work on Python 3.0 will in itself be a major challenge.
Getting mod_wsgi to work on Python 3.0 was in the end quite trivial
because the exposed WSGI interface is so small. The exposed interface
of mod_python at C code level is much larger and as such it would be
significantly more work. The combination of also having to change
Python code in mod_python means it would be practically impossible to
maintain one set of source that will work with both Python 2.X and
Python 3.0. There are also aspects of some of the mod_python code
which uses introspection which I am not even sure how you could port
them to Python 3.0 and have things behave the same way.
> I don't think mod_python is a competitor to mod_wsgi. Typically those
> trying that tutorial don't want to be forced to swallow a framework
> and to make a wsgi script application work it is necessary to deal
> with some things a framework developer deals with. The mod_python
> publisher fits that niche. It is easy to learn and you don't feel like
> pushing an elephant (a framework) into your living room.
There are two layers to mod_python and it is in some ways wrong to
call the whole mod_python, at least in the sense that the upper layers
are not really an essential part of the original purpose of
mod_python. What mod_python should be seen as is a way to integrate
code with the Apache request handling phases and filtering mechanisms.
As such, things like mod_python.cgi, mod_python.publisher,
mod_python.psp and all the HTML form, cookie and session handling code
is just extra cruft on top.
I would suggest that all these extras should never have been a part of
the core mod_python. They should have been distributed as a separate
package(s). The mod_python code should have stayed as a generic low
level solution for working with Apache, but it wasn't. Worse is that
questionable things were added into the mod_python core C code to
support these higher level packages rather than implement it as Python
code within the higher level packages.
Thus, if you ignore these higher level users of the Python/Apache
interface provided by mod_python, the main things that people use from
Apache are its ability to handle authentication, its content handler
phase and its input/output filters.
As it stands, mod_wsgi already has simpler and better hooks into the
Apache authentication mechanism than mod_python. It is also obviously
possible to implement content handlers with mod_wsgi. The only thing
from that core set of functionality of mod_python that some use that
mod_wsgi can't do is provide input/output filters. Doing that though
isn't hard and have more or less spec'd out plans for how it could be
done in a generic way in a similar style to WSGI iterables.
So, in terms of what the true core functionality of mod_python is,
mod_wsgi is very much a competitor and whereas mod_python is likely to
stay still, mod_wsgi isn't and thus will come to subsume what
mod_python can do in those areas and over time be able to integrate
with Apache in ways that mod_python can't currently do.
Now to your conjecture that there is no need for a user to swallow a
framework to use mod_python but they do if using WSGI, that is not
true. Just like those higher level layers of mod_python might be seen
as an anti framework, there are also anti frameworks for WSGI.
Probably the best one of these is Werkzeug.
Such anti frameworks for WSGI are though much better than what
mod_python provides as they are more easily pluggable such that you
have a greater array of technologies, eg, templating engines, that you
can use with very little or no effort.
One could contemplate taking the higher level handlers from mod_python
and porting that style of interface to WSGI, thus releasing you from
dependence on mod_python, but one really has to question if that is a
sane thing to do. The reason here is that those mod_python handlers
have an array of issues and do you really want to propagate them. If
you fix the problems though, you most likely break a lot of users
code, this is provided that you could maintain functionally equivalent
interfaces anyway.
Overall, mod_python is simply getting old and a lot has been learned
about writing Python web applications since then. Yes, the old ways
may still work, but it really is becoming a poor choice for the long
term given the alternatives now available.
BTW, I haven't even touched on the large list of technical issues,
problems and bugs in mod_python which are documented on the mod_python
issue tracker. When you look at all these as well, it becomes hard to
justify continuing with it. It is going to take one very very
dedicated person with a huge amount of spare time to keep the
mod_python project going, and as much as I have wasted huge amounts of
time fixing mod_python in the past, that isn't going to be me. It is
time for something fresh.
Graham
Clodoaldo
>
> 2008/4/10 Clodoaldo <clodoal...@gmail.com>:
> >
> > 2008/4/10, Graham Dumpleton <graham.d...@gmail.com>:
> >
> > > 2008/4/10 Clodoaldo <clodoal...@gmail.com>:
> > >
> > > > 2008/4/9, Matti Haavikko <matti.h...@futurice.fi>:
> > > > > Hello,
> > > > >
> > > > > Did Google App Server also make Apache HTTPD and relational databases
> > > > > obsolete?
> > > > > No - What Google just did, they pushed the world one big step closer to
> > > > > recognizing Python as ready for prime time web application development.
> > > >
> > > > 2008/4/9, David <dvke...@gmail.com>:
> > > >
> > > > > Matti has it right.
> > > > >
> > > > > Google's app engine has significantly raised the profile of Python as
> > > > > a web development language for many web developers.
> > > >
> > > > Coincidentally my mod_python/CGI tutorial had the visits number
> > > > doubled in the last 3 days.
> > >
> > >
> > > I think though it is time to put mod_python out to pasture though.
> >
> > You mean like taking the tutorial out from the web? Or like below just
> > ignoring the mailing list?
>
>
> What I am suggesting is that mod_python is in decline and that people
> should perhaps not be targeting it as a platform for application
> development going forward.
Thanks for the very complete answer. I have the impression that i
touched a hot spot not on purpose.
First let me say that when i mentioned the mod_python tutorial's
growing audience i was not meaning that it was a good choice to build
new applications on it. I certainly will not. I was just reinforcing
Matti and David's comments about GAE giving Python more visibility.
> A question for you so you understand what is coming. What are you
> going to do with all your applications that are tied to mod_python and
> cannot run on anything else, when Python 3.0 becomes main stream and
> Python 2.X is seen as legacy code?
I doubt Python 2.x will be missing from the distributions in the next
many years (can someone say 10?) and being seen as legacy code will
not change an applications' behavior. I will not port everything i
wrote just to be up to date. What is done is done. That said, since
mod_wsgi 1.0 release i didn't touch mod_python other than for
maintenance work.
> Unless some white knight comes along, I very much doubt that
> mod_python will ever be ported to Python 3.0, the code base is already
> somewhat unmaintainable at the C code level and working out how it
> should work on Python 3.0 will in itself be a major challenge.
>
> Getting mod_wsgi to work on Python 3.0 was in the end quite trivial
> because the exposed WSGI interface is so small. The exposed interface
> of mod_python at C code level is much larger and as such it would be
> significantly more work. The combination of also having to change
> Python code in mod_python means it would be practically impossible to
> maintain one set of source that will work with both Python 2.X and
> Python 3.0. There are also aspects of some of the mod_python code
> which uses introspection which I am not even sure how you could port
> them to Python 3.0 and have things behave the same way.
Sure mod_python should not deviate attention from mod_wsgi development
or from whatever builds on it.
> > I don't think mod_python is a competitor to mod_wsgi. Typically those
> > trying that tutorial don't want to be forced to swallow a framework
> > and to make a wsgi script application work it is necessary to deal
> > with some things a framework developer deals with. The mod_python
> > publisher fits that niche. It is easy to learn and you don't feel like
> > pushing an elephant (a framework) into your living room.
...
> So, in terms of what the true core functionality of mod_python is,
> mod_wsgi is very much a competitor and whereas mod_python is likely to
> stay still, mod_wsgi isn't and thus will come to subsume what
> mod_python can do in those areas and over time be able to integrate
> with Apache in ways that mod_python can't currently do.
Ok. In my limited vision i could only see the publisher in mod_python.
> Now to your conjecture that there is no need for a user to swallow a
> framework to use mod_python but they do if using WSGI, that is not
> true. Just like those higher level layers of mod_python might be seen
> as an anti framework, there are also anti frameworks for WSGI.
> Probably the best one of these is Werkzeug.
That got my attention. I will certainly try to get some understanding
on Werkzeug although i still don't know how different it is from, say,
stacking Pylons middleware.
Regards, Clodoaldo