FrontPage NonPersistentControlPanel / backlinks

Non-Persistent Control Panel Proposal

Note - this document is still a work in progress. Please do not make inline comments in the proposal - use the NonPersistentControlPanelDiscussion^x to make comments.

Contact

EvanSimpson

Problem

The Control Panel and its contents are Persistent objects, stored in the ZODB. This causes trouble for ZEOfied^x Zope installations, since either multiple clients try to recreate filesystem Product objects, or each one has to use a common Product object which may not accurately reflect the state of the Product in that client. If you delete the directory for a Product, the corresponding object remains until you manually delete it.

This persistence is pointless, since these objects aren't meant to be edited, they don't support Undo, and they can easily be recreated if they don't exist (and often are, anyway).

Since the root Application object and the Control Panel depend on the ZODB, in the event of a problem with the storage Zope cannot provide through-the-web diagnosis or recovery.

Filesystem Product objects aren't meant to be edited through the web, but nothing stops you from editing them in the current implementation. This prevents them from being purely informational objects. That is, they are more than just a means to check the status and configuration of filesystem Products. Since you can put persistent objects in them, they have to be persistent.

Proposed Solution

Separate through-the-web (TTW) Products from filesystem Products, perhaps even taking TTW Products out of the Control Panel entirely. Change the Control Panel and its Products collection into completely read-only, non-persistent objects used solely to monitor and control the state of Zope.

Make the Control Panel accessible regardless of the state of the ZODB. Even if the storage fails completely, allow users defined in the access file to navigate through the Control Panel in order to diagnose and perhaps attempt to remedy the failure. Provide a Control Panel view of logging messages emitted during Zope startup.

Every time Zope starts, it should create a Control Panel object and all of its subobjects. Objects in the Products collection should represent the status of filesystem Products only. TTW Products should be kept in a separate, persistent collection, perhaps not even in the Control Panel. ZPublisher^x should special-case access to the Control Panel so that it cannot fail due to problems with the state of the Application object.

Products should be able to mount read-only filestorages when initialized. These could contain help system data, or in the case of distributed Products the entire implementation.

Risk Factors

• It may be difficult to convert older databases containing persistent Control Panels.

• It is unclear where database configuration data such as cache settings should be stored.

• Implementation will likely require the use of mounted read-only storages.

Scope

This proposal covers an unfortunate amount of ground.

• Changing several fundamental objects from persistent to ephemeral

• Making Zope behave reasonably in the face of unusual failures during initialization.

• Reengineering Product distributions (TTW Products distributed as read-only tarballs)

• Changing the initialization of the help system, since Help objects would no longer be added to Product objects.

• Separating filesystem and TTW Products implies changes in the way Product features are accessed.

Deliverables

• A working implementation

• Database migration utility, or backward compatibility.

• Documentation of changes to Zope