I'm building a Zope2.10/Plone3 project using the CA wherever I can. I'm relying heavily on marker interfaces and I'm at a point where I need to allow a site administrator to create new marker interfaces to be used to mark content. I've looked at zodbcode, zope.app.module, and then finally found srichter's SchemaUtility work in zope.app.schema that was removed by jim in r69203. I'm only minimally able to make sense of this stuff, but none of it seems like what I'm looking for. I'd prefer to programatically create new interfaces than fake modules or other code object. Something like:: >>> from new import classobj >>> from zope.app.interface import PersistentInterface >>> app.IFoo = classobj('IFoo', (PersistentInterface,), dict(__doc__='IFoo')) >>> from zope.interface import directlyProvides >>> directlyProvides(app.index_html, app.IFoo) This actually all works except when the instance is stopped and restarted. When restarted, viewing index_html raises an error becuase the app.IFoo.depdndents PersistentDict is missing it's app.IFoo.depdndents.data attribute. I see that there's a zodbcode.patch.Wrapper used in zope.app.interface that seems like it's intended to resolve this issue but I have no idea how to use it. Actually, I don't have much idea what I'm doing at all, but I know what I want. :) I want to create marker interface programatically in response to a site administrators TTW actions and have them persist. I want to mark persistent objects as providing those interfaces (and, of course, have those declarations persist). In response to other site administrator TTW actions, I want to register adapters for objects that provide those marker interfaces and have those registrations persist (the adapters themselves need not persist, but that would be nice). I want this because the CA registry does exactly the kind of efficient lookup I'd like to do in this case. The only difference is that I don't want the marker interfaces and adapter registrations to be restricted to global code and I want them created through TTW actions. srichter, did SchemaUtility do what I'm talking about here? I see how it managed the persistent state of an interface established through global code, but I don't see how it could have resulted in the arbitrary creation of new interfaces TTW. Can you help me understand a little more what's going on there? Can anyone else advise on implementation directions or better design patterns? Ross