Ian Bicking: the old part of his blog

Re: There's so much more than Rails

Do you not still see lack of "commodity" hosting as a hurdle? That's always struck me as one of the biggest reasons for first Perl CGI, then especially PHP's rise to ubiquity.

This general case that web app development with python/ruby/(non-CGI)perl and friends has and still for the most part requires dedicated resources (mod_perl, FCGI, SCGI, etc.) has seemed to me to put them in the "non-trivial to deploy" category along with Java (and MS stuff(?)) ["deploy" in the find or config and setup a server and hosting and so on].

I'm guessing the plan is based around paste and wsgi and similar, which seems a good way of handling/building the ecosystem of pluggable apps and so forth, but what do you think about the deployment issue? A non-issue? At first I thought like many you're thinking more of those who can run their own servers, but since you specifically mention PHP I think this is a key point that would need to be addressed, no? Some ISPs are starting to offer FCGI and other options, but I'd say it's still pretty experimental based on the problems many have been having. Just wondering if and what you've thought of this area in your plan of attack...

Comment on There's so much more than Rails
by ToddG

Comments:

Do you not still see lack of "commodity" hosting as a hurdle? That's always struck me as one of the biggest reasons for first Perl CGI, then especially PHP's rise to ubiquity.

Absolutely; that's part of my plan! Perl CGI was one step; PHP was a different step (notable mod_perl is vaguely similar to mod_php, but the results are much different -- mod_php feels like Perl CGI in important ways). I think the next step will look similar to the app servers we have, but feel like PHP.

I'm guessing the plan is based around paste and wsgi and similar, which seems a good way of handling/building the ecosystem of pluggable apps and so forth, but what do you think about the deployment issue?

I have some ideas, written about here and elsewhere, and I'll try to actually follow through on describing the full plan after Christmas. But yes, deployment definitely matters, and I think there's several tools (most of which exist already) that can work together to make this work well. A lot of them aren't even Python specific. The recent Zope TTW discussions have some important ideas in them as well... the plan shouldn't just be plug-and-play, but plug-play-fiddle-plug-fiddle-play, or something like that. We have to invite users into the development process like PHP (and Zope TTW development) does, but also help teach them about basic development methodology.

# Ian Bicking

Todd,

I absolutely agree on this commodity hosting issue. Many "mainstream ISPs" for example don't support mod_python. And those that do are often more expensive. For many hobbyist programmers this is a clear advantage of PHP.

Regards, Roman

# Roman

"For many hobbyist programmers this is a clear advantage of PHP."

Hmmm... a think a hobbyist is someone who does something for fun. I don't think PHP is fun at all. On the other hand, Python is a lot of fun.

# Luis

Todd,

I absolutely agree on this commodity hosting issue. Many "mainstream ISPs" for example don't support mod_python. And those that do are often more expensive. For many hobbyist programmers this is a clear advantage of PHP.

Regards, Roman

# Roman

Isn't the problem with mod_python that python modules are writable? That makes shared hosting infeasible, since hosters are either faced with:

  1. purging all modules in between requests
  2. running apache in a separate process for each user

In contrast, PHP's modules are not quite as dynamic, being largely c extensions.

Perhaps someone familiar with hosting Python should come forward and identify current technical barriers to wider adoption of mod_python. Once these are solved, it should be easier to deploy python-based bulletin boards et c.

# Chui Tey