Welcome to Enterprising Plone Project

This project is an effort to make Plone more "Enterprise" by improving the infrastructure mainly to to support larger sites, but also to extend some functionality. The main driving force behind this project is to provide a possibility to migrate CPS 3 sites to Plone for those CPS users who want to stay on Zope. However, this aim is easily separated into several independent sub-projects of infrastructure improvements. Therefore, each of these subprojects could be of interest to you. Subscribe to the mailing-list or mail regebro@gmail.com if you want to help or have questions.

The sub-projects are as of today:

• Transparent document proxying
  CPS has a document repository where all documents are stored. In the content space only proxies appear for these documents. With this technique you can with very little effort have versioning, multiple-language documents and multi-location publishing. CPS's implementation has the drawback that it is not transparent whether  document is a real document or a proxy. All templates need to be aware of the proxying. That means you can't use this for a content type that isn't written for it. The proxying would need to work for any document type in Plone, and also it's necessary that the documents can be placed in content-space directly, as well as in a repository.
  During the snow-sprint some interested parties held a brainstorming session, and we identified these necessary features:
  
  • A ProxyWrapper object that wraps the object transparently
  • Original objects in content space or in Repository
  • Multidimensional version matrix (revision / language / country / etc )
    
  • Rules for version determination
  • Placeful workflow
  • Search should work
• Separating navigation from search (Suggested project name: PloneTrees?)
  Today the navigation are using catalog searches for all it's work. This means that the path index implementation (ExtendedPathIndex) is very complicated. This in turn makes it difficult to replace the full-text searching with another search engine. It also quite likely slows down the navigation. CPS used a very simple tool for creating navigation trees called portal_trees. It's very simple and quite fast.
• CommitHook registry
  In Plone, when you create or modify a document, it gets indexes several times. This is not only a waste of processing time, it becomes a real problem if you keep information outside the ZODB like in a Lucene index. Because the document gets reindexed (twice) any error that happens after the first reindexing will not roll back the reindexing, as the data is stored externally. The same problem appears if you store data in LDAP or SQL. Any error happening after the data has been written will roll backthe ZODB transaction, but it will not roll back the external data storage.
  The solution to this is to have a registry of commit hooks, that gets executed only during the transaction commit. Storing of data to external storages, or reindexing of data should happen only during the ZODB commit. With this it is also easy to make sure that an object gets reindexed only once, by not adding a reindex call to the action queue if it already exists.
  
• GenericSetup improvements
  CPS has some improvements to GenericSetup. Most importantly, the upgrade steps is a way to easily make upgrading scripts that know when they need to be applied. This should be merged into GenericSetup proper.
• Persistent schemas
  Most CPS sites have their schemas in the ZODB. This allows for TTW creation of new content types, and it allows for easy customization of existing content types. For this, we either need to create persistent archetypes schemas, or we need to port CPSSchemas and maybe CPSDocument to Plone (this is probably easier, but less neat).
• IncrementalSearch as ZCatalog engine.
  ZCatalog performance breaks down when you have large sites (supposedly around 300.000 documents, although I haven't tested myself). This is at least partly because ZCatalog creates large intermediate result sets during the searching. The internal ZCatalog engine should be replaced with Dieter Maurers IncrementalSearch to get rid of this problem.
  

We are currently in need of developers for all subprojects. If you are interested of any of these subprojects and think you can help, send a mail to the mailing-list. If you need any of these features, but are not a developer, you can help by funding development. Currently we don't have any funding manager, but we hope that the Zope-foundation will organize the funding in the future.

Lennart Regebro
regebro@gmail.com