[mod_python] persistent, reliable globals

a good point, vincent.

another more general question might be: given the proliferation of
application server frameworks, why another one?  the ironic thing is
that i decided to make this kit because i was not happy with how other
frameworks were "reinventing the wheel" (from my point of view.)

what do i mean by this?

1) no extra servers: running another server behind apache is not that
difficult, but it seems like a waste to not use apache itself as a
server.  e.g. use the apache process model (which will be more
thoroughly tested than any server i will write), http / ssl server,
request processing, configuration, logs, etc.

2) no toy languages: python is an excellent language.  use the
features of python (and not some funny interface to the features of
python) for your framework.  this means: use objects, modules and
packages, not a domain-specific component framekwork.  and, no
preprecessors / compilers: straight python.

an example: i'm often think "what is really going on" when i read big
configuraiton files.  i've decided to make my configuration files
actual python, so it should be clear!

3) be relatively feature-full.  this means: sessions, cookies,
authentication, caching.

1+2 = python programmers don't have to learn anything to get started.
i think grisha's publisher framework is a good example of this.

less important and unrelated concerns:

4) template / database neutrality.  personally i'm anti-template, but
i see their usefulness, but people have religious opinions / legacy
systems to worry about.

5) finally, i selfishly want to see mod_python everywhere, like
mod_perl, so i thought by making a great framework that was tightly
bound to mod_python would help.

ok, now my humble evaluation of some existing frameworks: i don't want
to start a flamewar, so let me start off by saying i really like a lot
of these, except where i say otherwise, and my opinions certainly
aren't set in stone if people want to convince me otherwise.

zope: well this one i'm not a fan of.  there are plenty of anti-zope
web pages out there, so i'll leave it at that.  skunkweb, webware, and
cherrypy are all really much better, imho.

i've used skunkweb for a commercial site.  its caching and performance
are reputable, and is generally pleasant to use.  my complaints: its
session handling and authentication is less-than-mature.  (i
contributed some code to this.)  stml is nice, but i'm not a fan of
the component framework, which makes pages in a piece-meal fashion,
not in an object-oriented way.  the request processing framework is a
little hard to understand, or at least not well documented (though
this might be changing soon.)  the configuration is powerful but a bit
overwhelming.  (there's a FAQ "my config file is so big!")  it doesn't
install out-of-the-box into freebsd (what i use).

cheerypy i've played with.  i like it a lot too.  however i'm not a
fan of the toy language.  i've stolen remi's idea of using aspects in
web programming (which admittedly is a very old idea), but without a
preprocessor.  the fact that it is a compiler makes it hard to grovel
the source: your code gets munged together with a bunch of other code
which is hard to figure out where it came from.  again it has a
component framework which, while closely mapping to python's, is in
the toy language.  (i can't get emacs to do intentation properly!)
but it certainly is lightweight and object-oriented, and relatively
well-documented.  i had a lot of fun writing some test pages, and even
contributed a bugfix (to the authentication code, again.)

webware i've only read about so probably shouldn't comment on.  but i
will say after working at a startup, i have a phobia of phrases like
3-tier, etc.  people seem to like webware though so maybe i should get
over my prejudices.  it's trying to be complete in a way that i'm not:
i think they want to replace zope (which is an admirable goal.)  i
don't want object-relational mappers built-in, i just want to control
how requests get processed and sent to you.  i do like using the java
servlet model though (which i've adopted: my kit is called "pylets"
for now.)

pyro is really cool.  certainly it is an interesting way to go.
however i'm interested in tight binding with apache: no separate
server process to manage, use the apache logs, and of course the
performance you get by being inside apache.

i'm a couple days from pre-alpha release, mostly documentation work.
probably these emails i'm writing may form the start of the docs.
sorry to flood you all with my ramblings.  i hope people will play
with it, once it's out.

take care, Ben

On Wed, 10 Mar 2004, vincent delft wrote:

> Have you look at pyro (http://pyro.sf.net).
>
> It's not a middleware, but will allow you to "play"
> with Python object throught the newtork.
>
> Pyro has caching mechanism.
>
> As mention earlier, xml-rpc is a possibility too. no?
>
> Those tool combine with mod_python is a powerfull
> framework, no ?