History for CMF 2.0 Roadmap

??changed:
-
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

  o 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:

      o Zope 2.8 3+

      o Five 1.2+ (to enable local site managers)