Previously Tres Seaver wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jim Fulton wrote: > > On Sep 3, 2008, at 3:57 AM, Martin Aspeli wrote: > >>> I guess the simple solution is well it you don't like it, use the > >>> another framework. Its not quite that simple since I am extremely > >>> fond > >>> of the CA architecture and have a strong desire to continue with it > >>> in > >>> some form or another into the future. I think what I am sensing more > >>> than anything is a need for zope to adapt a changing reality. > >> zope.component, at least, is one of the packages that *does* work > >> without "the world". :) > > > > Only partially and only because I did something I really didn't want > > to do, which was to employ extras. > > > > ... > > > >>> I believe much of what is being accomplished in > >>> bfg could be accomplished in zope if it were tighter and we could > >>> focus > >>> on a leaner core of packages void of the large number of > >>> dependencies. > >> Reducing unneeded dependencies would indeed be a good architectural > >> goal. However, I'm not sure that having a few extra packages today is > >> stopping people from getting things done. > > > > I think there is a distaste for having lots of extra packages around. > > This isn't very important to me, but it really bugs some folks. > > Extra dependencies impose burdens on every *client* of the careless pacakge: > > - Everybody has to download and store the pacakge, which wouldn't > be so bad for one-time use, but lots of times "rebuild the world" > (including blowing away caches) can be a useful strategy. > > - The cognitive load is non-trivial, even in the mythical universe > where every package has readable and useful documentation: not > needing to consider a package's documentation is better than reading > it, for the case that it is truly unneeded. > > - Debugging is tougher, especially in the face of auto-included ZCML. > > - Auditing the dependent application is harder when there are not- > really-needed pacakges in the mix. > > - Runtime footprint issues (RAM usage, startup time) are also > worth onsidering.
- The chance of a conflict when one of the many packages in your project sees a new release increases reapidly Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )