Proposed by
Stephen Compall
Seconded by
None as yet
Proposal type
Core
State
being-discussed
Motivation
A frequent complaint of newcomers to Plone deployment and development is the use of Zope to provide features such as HTTP request handling, object persistence, transactional safety, and load sharing. It is difficult enough to learn one large system at a time; by requiring the learning of two large systems, Plone effectively makes things twice as hard for newcomers. It is also inconvenient for users to have to install Python 2.4 when they frequently already have 2.5 or 2.6 installed.Plone is now large enough that it should be able to stand on its own, without Zope.
Assumptions
This proposal suggests the removal of Zope only. Others have suggested, variously:- Removal of Python dependency;
- Allow extension via CLR;
- Allow extension via PHP;
- Portability to abacuses.
Proposal & Implementation
By removing all imports of Zope Python packages and fixing any problems indicated by unit and user testing, and possibly replacing remaining functionality that Zope might provide with Plone-specific packages, we can remove Zope entirely from future buildouts and installations. A wider variety of Python versions may also be used.Deliverables
Included are:- New versions of all Plone packages with Zope dependencies removed.
- A new paster to replace ZopeSkel, with a buildout skeleton that does not include the zope2instance recipe.
- New Plone packages as needed to replace remaining Zope functionality that might be convenient.
- Replacement of all mention of "products", a decidedly Zope-centric term, with "goodies".
Risks
Users of add-on packages that have not been ported to become goodie-compliant by removing their Zope dependencies may have trouble working with a Plone implementing this proposal, and make take a little time to port.To mitigate this inconvenience, we might offer a compatibility package, Nine, which provides features of Zope 2 and 3 for Plone 4 add-on goodies that need them.
+1
ReplyDelete