Benji York wrote:
Christian Theune wrote:
Same here. I'm feeling like I'm not yet understanding what the trunk
will be used like.

I'm wondering if we need to maintain a Zope 3 project with any code in it at all (or nearly so). Could "Zope 3" just be a buildout with a configuration that creates a "Zope 3 application" with a bunch of stock components.

Christian said we should wax philosophical and since this one of my favorite activities I will belatedly do this. :)

It is instructive to look at TurboGears. They were the pioneers of egg-based distribution and used cool words like 'megaframework' to market the concept of various libraries being integrated into one framework. Django in contrast spreads memes like "yeah, megaframeworks are nice, but we're INTEGRATED". So we could market Zope 3 as "the integrated mega-framework". :)

TurboGears is different from Zope 3 in that most of its component parts are libraries developed by independent communities. This is less the case for Zope 3, though some of its constituent parts are similar (ZODB for instance). As time progresses we might eventually see more smaller communities form around smaller parts, but we'll see. If I read Jim right, we should be careful about splitting up the community prematurely, so let's all keep it on this list for the time being. :)

TurboGears is also different from Zope 3 in that there is an actual turbogears package out there. This contains the code that glues the libraries together into a more coherent experience. With Zope 3 the responsibility for a coherent experience is diffused over numerous packages, though one can argue that zope.component and zope.interface play the most important roles here.

It's interesting to consider Grok in this light too. Grok tries to encapsulate various patterns of Zope 3 and offer them in a more convenient to use form. In this, it might be somewhat similar to the role the turbogears core package plays, but of course only to people who actually use Grok. :)



Zope3-dev mailing list

Reply via email to