[Zope3-dev] Two visions

[Jeff Shell]

On 2/28/06, Martijn Faassen <faassen at infrae.com> wrote:
> Gary Poster wrote:
> [snip]
> > On Feb 28, 2006, at 10:06 AM, Philipp von Weitershausen wrote:
> >
> >> I think focusing on one app server and a dedicated set of libraries
> >> would be a good alternative to two concurring app servers.
> >
> > ...if the single app server is based on acquisition,  __bobo_traverse__
> > and friends, objectValues and friends, ZCatalog,  and so on, I'd rather
> > have two, thanks: at least I can have one I like.
>
> I can see where Philipp is coming from: yes, it would be good to
> collapse the Zope 2 and Zope 3 communities into one if that frees up
> more development resources and lets us do less duplicate work.

I still fear collapsing them into one. This is no offense to any of
the hard work people are doing on all projects. Someone said "Zope 2 +
Zope 3 + Five is big complexity", and I agree. A lot. It's easier for
us to use only one or only another. I prefer Zope 3. It's simpler. But
already there are some design decisions that have happened in recent
months that make me less comfortable about that.

All of these big features are neat and well. But I want less. I don't
know how to use less. There are dependencies on zope.app creeping into
packages allowed in zope.*, and I understand that more of that is
likely to happen in the future. And that terrifies me.

An acknowledged Zope 2 problem is the large inheritance structure that
objects have to support to be useful and usable, and that it creates a
tight coupling that can't be broken.

But having a large collection of loose couplings that can't easily be
broken is not a better solution. Having to load up and configure 80%
of the zope library to use 30% of its features isn't tenable. The size
of Zope 3 "app server" as it stands now is still overwhelming to me.

I think we could still stand to do with some smaller cleaner core
features first. The part of this vision that worries me tonight is
that it gives priority to the Big Complex Application Server With All
It's Features (as good as they may be). Instead we could do good by
giving that thing a better base to use, and benefit others among us by
having a better base to use with less overhead (says the man bit by
ZCML browser dynamic class generation again today). IE - move some of
the *core* widget concepts out of zope.app and into formlib, and
finding ways of severing the zope.app dependency from zope.formlib.
Move some of the core interfaces up a level, and make the ones in
zope.app.form extend those core ones.

If "application server" (still a term I'd like to see defined in this
context) becomes a priority, or a separate priority, or we just start
thinking about what needs to be done to make core things simple,
powerful, and sharable; and how to build the Application Server on
that to give people a variety of development/deployment options or
pre-built tools to help with so-called "large applications" then I
think this could be a good thing.

But if it all becomes one big overwhelming library/server/solution
again, I can't stick around for that. I don't need something with the
weight of Plone or the CMF to make an itinerary manager. Super
terrific content management tools aren't going to help me build a
state heavy e-commerce application. Getting too tied up in the
concepts of containers/containment/"all objects are like this"
mentality isn't going to help us deliver a sprawling enterprise
payroll management system from five different data sources.

The loose coupling of Zope 3 makes doing these different systems in
Zope using a similar development technique for each possible. I want
to make sure that the loose coupling remains useful and usable, that
trying to use a particular widget isn't likely to make my system need
to register 80 supporting components and sub systems. Hopefully some
simple guidelines can stay in place and stuck to in regards to "how to
make sharable components sharable".

--
Jeff Shell