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 <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.