Web Application Servers in Python: Hopeful Monsters ?

[Graham Dumpleton]

George Planansky <george_planansky at harvard.edu> wrote in message news:<w3yd75843at.fsf_-_ at ns1.das.harvard.edu>...
> The current situation with pythonic web software seems analogous to
> the evolutionary situation that pertains with the opening of a new
> biological niche, as e.g. with the denizens of the Burgess Shale,
> ca. 600 m.y. B.P. .  That makes Zope, Webware, et. al., pythonic
> "Hopeful Monsters".
> 
> Small comfort to those wondering which horse to ride.  A better 
> question might be, "Which trilobite?".

An interesting analogy and in some respects quite apt.

One difference perhaps with traditional concepts of evolution is that
most of these software packages aren't produced as a result of gradual
evolution from something which came before. Thus, rather than being
based on something which already existed and which had shown its
strength, durability and apropriateness for the task, most of these
"hopeful monsters" just spring into being, a sort of frankenstein,
born out of the gene factories of mankind.

I would however also hazard to make the comment, that although Open
Source and collaborative development by a disperse group of people
does in some cases produces good results, some software packages tend
to suffer the "design by committee" syndrome. What I mean here is that
they lack a bit as far as vision and overall good design. This comes
about because the design gets driven by the herd, as opposed to there
being one person who can see what could be achieved and is the sole
driving force in getting it done and getting it done right.

This frankenstein approach to birthing such software packages, means
that they often try and do too much initially. A result of this is
that they are often not very modular and you have to buy into the
whole thing as opposed to being able to use just some bit of it. This
can make then somewhat useless if you need to produce something which
is quite customised to a specific need.

The fact that the design is driven by the herd also means that
additional features often get bolted on in an adhoc manner without
good insight as to whether that is really a good thing. Once those
features have been added however, if they are found to cause problems,
they are more often than not left in rather than dropped as being a
bad evolutionary path as would happen in nature. This happens because
people have become dependent on them, or more correctly on the API,
something which might have been avoided to a degree if there were
better separation between the mode of interaction and the
implementation itself in the first place, which gets back to the need
for good design.

Thus over time you get multiple ways of doing things, each with their
own warts and sometimes with little evidence of learning from past
mistakes. One often wanders sometimes whether the developers of these
packages even look at other packages already available, whether they
be in the same language or another. Many ideas these packages embrace
have been around for many years, but they are seen as being new. They
might perhaps be new to the developers, but all this means is that
they don't address the problems which have shown to be implicit in
such an approach.

I also see part of the problem with some of the so called "web
application server" packages as stemming from these packages trying to
be a web server first, with the actual application infrastructure more
of an after thought. Thus, they might be quite useful where all you
want to do is produce fancy web pages, but when it comes to using it
as a front end into an application, especially a distributed
application, they can be quite lacking.

I thus personally believe that one is better developing the
infrastructure to support the application first. Where this
infrastructure is not in any way dependent upon a web server for it to
work. The model of an even driven messaging system is one approach to
this which can work. Using such an infrastructure one would use
request/reply and publish/subscribe functionality to support the
actual application. The web interface should then merely be a bridge
into this infrastructure as necessary.

In evaluating these packages, one really has to sit down and work out
what it actually is that you want to do. Is what you want to do driven
totally by the web interface or is what the application does
independent of the web interface more important. From what I have
seen, even if it is the latter, most people go towards packages more
designed for the former. The consequence being that they just make the
job harder for themselves. A situation which can quickly get worse as
the application grows in size and holding it all in one application
process becomes unrealistic.

Again, not an answer as to which is best, as which is more suitable
will really depend on what your doing and your personal philosophy as
to how you like to do things. Each packages has it warts and its good
points and some are documented better than others. Choose your poison,
or make your own. ;-)

FYI, yes I do produce a package of my own which could be labelled as
partly being a "web application server". I really don't like that term
however and am not really sure what it is mean't to mean, the package
I produce actually does a lot of other things as well. As with the
listed packages, my own package has its own warts and things I would
like to change and make better. I am therefore not writing the above
commentary because I believe I have something which is better than
those packages. To even make such a judgement isn't even appropriate
as each tries to address different requirements anyway.

> "Thomas Weholt" <thomas at gatsoft.no> wrote:
> 
> > 
> > My experience with the ones I've tested ( Zope and Webware ) is that if you
> > can find either products ( in zope ) or allready existing features in the
> > system that fits your needs, you might get productive rather quick. If you
> > on the other hand want to develop highly customized solutions you might have
> > to invest more time and possibly money. How you like to work, if you like
> > using *SP-based solutions like DHTML in Zope and PSP and Webware etc. will
> > also play a big part in deciding what package you want to use. I think
> > Webware and Zope work just fine if you're way of working is compatible with
> > the concept behind one of those packages.
> > 
> > I found Zope too complex, almost bloated, Webware was interesting and showed
> > alot of promise, but failed to invoke serious interest. I've started
> > developing my own application server based on Medusa and take parts of the
> > concept behind Zope, Webware, other Java-based application servers like
> > Tomcat and Enhydra and it's coming along nicely, soon becoming ready for a
> > beta-release. I wanted 100% control of my code, complete seperation of
> > design and code, "web-components", simpler user/access-management etc. and
> > at the same time learn how it all worked, that's why I decided to create a
> > new project.
> > 
> > Perhaps no real answer to your question, but ...
> > 
> > Thomas
> > 
> > "Weet Vanniks" <Weet.Vanniks at el_simpatico.be> wrote in message
> > news:3B9364F8.2C477597 at el_simpatico.be...
> > > The subject title says it all or almost ...
> > > There seems to exist a great offering:
> > > Zope, Bobo, Webware,SkunkWeb, Quixote,Twisted, etc...
> > > This makes my choice very difficult. Can I get an unbiased opinion about
> > > the merits of each of these solutions. I've been told that Zope is
> > > complex and that Webware is great. Could you confirm ?
> > > Thanks for helping me out.
> > >
> > > Weet
> > >