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
> still.

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 - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to