Hi Martin. The concern is building high volume applications using z3,
the memory footprint for virtual hosting, and the unnecessary code that
adds to burden of managing security. **I only want the code I use**.
I agree that the current situation does not stop folks from getting
things done but overall z3 as a development platform is looking not so
attractive for these reasons. It is analogous to packing two suitcases
of clothes for a trip and finding you just needed a change of underwear
and a shirt. Frankly is just getting difficult to accept the status quo
anymore so hoping folks can get behind this sort of effort.
I am trying to avoid the need for selective forking that Chris has found
necessary to make progress with bfg. I want to continue using zope since
these things are a big factor for the factors I stated.
Martin Aspeli wrote:
> Hi David,
> David Pratt wrote:
>> I am feeling increasing pressure and frustration to re-examine what I am
>> doing. Zope has a wonderful code base but it is spread through many
>> packages in the form of dependencies. As a result, a small app in a
>> working z3 setup can start off at almost 50MB while the similar app on a
>> competitive framework may be as little as 15 - 20 MB.
> Are you worried about disk space? Memory footprint?
>> 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". :)
>> bfg is a relatively new framework that builds on wsgi and zope
>> technologies but is an example of what can be achieved if you consume
>> only what you need.
> True. I'd say that repoze.bfg is very much part of the Zope world,
> though. It's an example of what Zope (and it's splitting of things into
> many packages) has made possible.
>> It is attractive in a number of respects for zope
>> developers since it offers simplicity and development speed with a
>> lightweight footprint.
> Yep. It's nice. :)
>> 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 are couple of options. One option would be to set about on
>> a course of change to do something about this with the existing
>> codebase. Another option is to create a core of leaner packages that
>> could result in a much smaller, tighter core that can be competitive
>> with the changing python landscape.
> I'm not sure that another "armageddon" of Zope - starting it all again
> in search of something "better" - will serve anybody or go particularly
> far. I don't think that's what bfg is doing; I think it's using the
> power of Zope 3 and the CA to selectively swap out the bits it doesn't
> like for new bits. I see that as Zope delivering, not Zope failing.
>> bfg is currently taking the option
>> of selectively forking some of the packages such as zope.catalog as
>> repoze.catalog for example. Personally, I would like to see these
>> changes occur in some way within zope.
> +1, but only where it actually makes sense. I'm not sure about
> repoze.catalog... but quite often, you may get a repoze.* that's just a
> wrapper around a zope.* package to make it easier to integrate with a
> particular framework (bfg). That's the way re-use normally happens, I think.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -