Hi all, zope.catalog is a crucial part of ZTK, as it adds the equivalent of RDBMS SELECT queries to our ODB based apps. However in my opinion its default setup is suboptimal as a generic library in ZTK, because it is hardwired up for ZMI "point and click" operation. As soon as you create and register an ICatalog utility, every ObjectAddedEvent and ObjectModifiedEvent will trigger stuffing the object into intids, and each intid registration event will trigger an attempt to index an object. When you add an index to the catalog, it gets reindexed automatically. Because these behaviours are implemented by event handlers, there is no way for an app to override or disable them. There is an "opt out" mechanism for keeping objects out of the catalog (INoAutoIndex, INoAutoReindex marker interfaces), but curiously the latter does not inherit from the former,so your object can be indexed on modification even if you made it provide INoAutoIndex. Automatically stuffing all newly added objects into the int ids utility and then further into the catalog is bad, because, first, it cripples any alternative uses of the int ids utility, turns it into purely a catalog accessory, and second, places some restrictions on containers and contained objects due to the persistent oid based key reference implementation. About a year ago zope.app.catalog as been moved to zope.catalog. I think during this move there was a unique opportunity to leave these event handlers behind in zope.app.catalog, so that the "no .app" version is free of these forced choices. But perhaps it's not too late to do in now? After all, no stable version of Zope 3 / ZTK codebase has been released after this move? People relying on automatic indexing would have to register a couple of event handlers in their configurations (or include zope.app.catalog), but the rest of us would be able to choose the policy of how and when the objects are registered with IntIds and indexed in the catalog. Albertas -- http://www.pov.lt/ -- Zope and Python consulting