CMF 2.0 Roadmap

Overview

As of the CMF 1.5 release line, the CMF seems to have reached a fairly mature state: new features are mostly doable via "add-on" products (e.g., via CMFUid?, CMFSetup?), and bugfixes dominate changes to the original packages. Some of this maturity can certainly be attributed to the growth of Zope3 as a target for new development; indeed, one might view Zope3 itself as an outgrowth of the architectural ideas first sketched in the CMF.

Projects and users who currently depend on the CMF are, naturally, considering how they can begin to leverage the new and ongoing work being invested into Zope3, including the proposed "enterprise content management" features being proposed at http://www.z3lab.org/. Their existing investments, including custom software, skins, and persistent data, make wholesale adoption of those technologies difficult, even given the migration possibilities offered by the inclusion of Five into Zope 2.8.0.

This roadmap attempts to lay out a course of development for the CMF itself which makes it possible for such projects and users to migrate gradually toward Zope3 / ECM, on top of the CMF platform, rather than in spite of it.

Why "CMF 2.0"?

In order to provide a platform for migration, the CMF will need to make some fairly significant changes in its implementation:

• Content objects need to expose Zope3-style interfaces;
• Presentation elements need to move from the current skins into views;
• "Application logic" needs to move from either content classes, tools or skins into adapters / utilities.

Because such changes are going to introduce new APIs?, and may require some non-trivial migration of persistent objects, this release will take a new major version.

Backwards Compatibility

Persistent data presents an especially tricky problem for backward compatibility: "old" data can linger indefinitely within the object database, and may be difficult to update cleanly. Further, the introduction of code to maintain such compatibility introduces its own set of risks: such code is typically fragile, and often a source of new and hard-to-reproduce bugs.

This roadmap therefore presumes a mixed strategy for backward compatibility: where possible, we will supply the new functionality via the component architecture (view / adapter / utility lookup), while leaving the old features "in place" using their current implementations. When such "parallel" deployemnt becomse infeasible, we will adopt the strategy used almost universally by RDBMS platforms to cope with data migration: "dump and reload".

CMFSetup? already provides a framework for exporting the policies and configurations represented in the CMF tools. We will continue to extend this framework, and will investigate the possibility of using the exported configuration data to drive the creation of a migrated site.

For content, as opposed to tool configuration, the CMF currently does not have a workable export / import framework. This roadmap presumes that we will develop one, perhaps targetting a filesystem representation compatible with other CMS tools (e.g., the Java Content Repository spec, http://jcp.org/aboutJava/communityprocess/final/jsr170/index.html).

Proposed Roadmap

• CMF 2.0.0alpha1, 2005/11/10
  • Zope3 interfaces for all content classes and tools
  • All "content view" template / script code migrated to Zope3 views
  • Views emit Zope3-style content and container events.
  • GenericSetup? split out from CMFSetup?, with tool / content adapters specific to the CMF remaining in CMFSetup?.
  • Content export / import adapters available (using the FTP / DAV representation) for all CMFDefault? content types.
  • Dependencies:
    • Zope 2.8 3+
    • Five 1.2+ (to enable local site managers)