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
NonPersistentControlPanelDiscussionx to make comments.
The Control Panel and its contents are Persistent objects, stored in
the ZODB. This causes trouble for ZEOfiedx 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.
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
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. ZPublisherx should special-case access to the Control
Panel so that it cannot fail due to problems with the state of the
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.
It may be difficult to convert older databases containing persistent
It is unclear where database configuration data such as cache
settings should be stored.
Implementation will likely require the use of mounted read-only
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
Reengineering Product distributions (TTW Products distributed as
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.