Bud P. Bruegger wrote:

> With pyContainer http://www.iem.pw.edu.pl/~sniezynr/pycontainer/  and
> PEAK http://peak.telecommunity.com/ there are now two Python "component
> frameworks" that use the Inversion of Control Pattern and lightweight
> containers to make it easy to create reusable components that can be
> flexibly combines.  These concepts that are big and hot in the Java
> world.  They also seem to bring the some of the complexity of the java
> world with them.
>
> To me personally, the examples of use that I have seen so far seem so
> simple (maybe for didactic reasons) that the proposed solution seems
> overly complex;  so they haven't convinced me that I really should need
> the additional complexity of light-weight containers.

Forgive the long-winded answer, Bud... I should add up-front that I've
never used containers, and I've only played with PEAK. I have used
PyProtocols (a part of PEAK) and think it is a Great Thing, but it's a
small part of the whole container/framework issue.

I've been thinking about this a lot over the last few days. When the
thread about a new Issue Tracker began, I was excited; but also
frustrated, because I expected to see Yet Another Issue Tracker that
would be difficult to use or install because of the authors' design
choices. Most frequently, it's a specific choice of database; other
times it's a specific Web server (Apache, or mod_* something) or it's
just designed in a way that would be hard to integrate with an existing
application.

When the question arises -- should I hack at one of these apps to make
it work in my environment, or should I just roll my own? -- I usually
choose the latter, unless the features of the existing app are so
compelling that a reinvention would be a real time-waster. Whipping up a
simple Issue Manager, for example, could be done in half a day if you
had a good idea of what you wanted, and you intended to deploy it only
in your prefered environment.

(A fellow Quixote user pointed out, off-list, that component-oriented
software is hard to design without a series of releases. First you
design it for yourself; then you share it with friends who have slightly
different needs; later it becomes free software, publically available.
In each context, the requirements are different, and the design
constraints change accordingly.)

Containers alone wouldn't solve these problems. One could write a
monolithic, unconfigurable application, and run it in a container;
similarly one could make many, but poor, choices when dividing the
application, and end up with a configuration nightmare. What is key is
the wise selection of points in the application where you divide it into
smaller blocks, and how you configure those blocks. That can be done
with plain-old Python source, good selection of constructor signatures,
and a sensibility about interfaces (whether formally-specified or
organically grown, like Python's "file-like objects").

I do think componentization is a good thing. For example, it would be
very nice to have a well-designed User Management component that could
be embedded in an application, and/or shared among multiple applications
on a server. Reinventing user-management interfaces for each application
seems like a waste of time. It's hard to write one that meets everyone's
needs; but it would be a worthwhile undertaking to try. The mere
existence of such a (well-conceived) module should motivate designers to
use it, or imitate its interfaces (user and/or back-end); either way we
begin to settle upon a User Management Interface that would do for
user-management what the WSGI work on the Python Web-SIG promises to do
for Web-server connectivity: add interoperability and reuse at the edges
of our applications -- not where our app logic is, but where the boring
stuff happens.

I hope we haven't lost touch with the initial idea of building an Issue
Manager in Quixote; and I also hope that all this talk of components
hasn't introduced "analysis paralysis" to anyone who had begun sketching
a system. I just hope that we can *eventually* factor out the boring
stuff (database, mail delivery, user management) into modules/components
that have well-grown interfaces, so that other parts can be substituted
if the need arises.

> Is there something I'm missing out of and there are some killer use
> cases that demonstrate how containers make the solution of problems
> actually easier than doing without containers and framework?

Until a container can abstract persistence to the point where I don't
care if it's Oracle, ZODB or a set of text-files on the back end of my
application (never, perhaps?), I suspect that their usefulness is
limited largely to separating configuration from logic. And that can be
done without containers.

Best,

-- Graham