experimental.broken - Graceful handling of broken interfaces and components in the ZODB

Please take a look at experimental.broken:

https://github.com/rpatterson/experimental.broken
http://pypi.python.org/pypi/experimental.broken

The handling of broken objects by the ZODB can make an application with
add-ons that use zope.interface far too fragile.  If marker interfaces
from an add-on are used on objects in the ZODB, removing that add-on can
make any zope.interface operation on that object fail.  Even worse, if
an add-on registers any components in a registry in the ZODB, that
entire registry will become unusable for any ZCA operations which pretty
much breaks everything, including admin interfaces.

Since the interfaces and the ZCA are often core parts of an application
using the ZODB, it may be appropriate to add special handling for broken
objects to those services.  The experimental.broken patches are my
attempt to prototype such special handling.

For objects in the ZODB which directly provide a marker interface,
these patches allow that object to behave as without the application
of the marker interface if the interface is no longer available.  If
the interface is made available again, the full behavior of that
interface is restored.  Similarly, if a component whose class,
provided interface, or required interfaces are missing, these patches
allow the registry to perform lookups it would have been able to do
without the broken component registration.  If the component
class, provided interface, and required interfaces are restored,
then the component registration is fully restored.

If an object or registry in the ZODB is committed to the ZODB with
broken interfaces or components, the commit will succeed and it is still
possible to fully restore previous behavior if the missing classes and
interfaces are restored.  Unfortunately, because interfaces are pickled
as globals, there's no good way to have the same pickle written on
commit for the interface as was in the original pickle, but it should
behave exactly the same.

The intention of this package is to see if the implementation of broken
object handling is correct and robust enough to merge into
zope.interface and zope.component themselves.  Is this the right
approach?  If not why and what would be better?  How might this approach
be improved?

Ross

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1