On 2/28/06, Martijn Faassen <[EMAIL PROTECTED]> 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 _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com