[mod_python] persistent, reliable globals

I believed you just summed up albatross/draco's take on "the wheel".  I
prefer Albatross, but you should look at both:

http://www.object-craft.com.au/projects/albatross/
http://draco.boskant.nl/

Mike

> -----Original Message-----
> From: Ben [mailto:ben at medianstrip.net] 
> Sent: Wednesday, March 10, 2004 1:55 PM
> To: vincent delft
> Cc: mod_python at modpython.org
> Subject: RE: [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 ?
> 
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
>