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 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
** No cross posts or HTML encoding! **
(Related lists -