Hanno Schlichting wrote:
> The "Zope Framework" as defined as zope.* is far less than Zope2
> requires itself. zope.app.testing, zope.app.component, zope.app.form,
> zope.app.publisher and friends are all used and incur a major buy into
> the Zope3 Application Server today.
Hm, zope.* in my document is meant to entail zope.app.*, so those aren't
a problem. :)
It is my hope we can continue weeding out zope.app.* packages, leaving
the ZMI behind and moving frameworky bits into pure zope.* packages.
Eventually we'll end up with a Zope Framework that won't have zope.app.*
stuff, but that's the future.
> So Zope2 does have an interest in a maintained Zope3 KGS and release
What do you mean by "Zope 3"? Zope 3 the app server or Zope 3 the
framework? Zope 3 is an overloaded term and you should use it with caution.
A Zope Framework that Zope 2 can't use is useless so I wouldn't worry
about the Zope Framework team cutting out packages just like that; if
the developers do their job right that won't happen.
> From my Plone perspective I do have even more of an interest in the Zope
> 3.5 KGS. In the high-level applications I built, z3c.form, zope.intid
> but also z3c.unconfigure and many more packages are often used. Being
> able to rely on a KGS of such a wider set of libraries is valuable to me.
That's a good point. So we'd need a core + extra KGS, where extra
packages that opt in are also included.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -