ben at medianstrip.net
Wed Mar 10 13:54:59 EST 2004
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 ?