[Framework-Team] five.intid and object_implements index in Plone 3

[Martin Aspeli]

Hi guys,

I'm toying with the idea of introducing five.intid as a dependency for
Plone 3. Whit is responsible for this creation, so I'd like this input
as well, but from discussions with him it seems quite useful.

 - It can be combined with Zope 3's catalog implementation
 - It can act as a generic reference catalog
 - We (I) could simpilfy plone.app.redirector a little bit by using it
instead of a custom path storage (well, the storage would still need
to be there to remember where things used to be, but it would be a bit
more standards-based)
 - We could use intids in more generic places like that fabled
selection widget. That is, we don't have to rely on context.UID().

If you want to see it in action, the doctest is very descriptive and
easy to follow:
http://svn.plone.org/svn/collective/five.intid/trunk/five/intid/README.txt

I think setting it up would be quite easy:

 - Add to the bundle
 - Add a subscriber for Products.CMFCore.IContentish, so that it takes
care of all content
 - Add a migration step to add the utility
 - Possibly add a step to index existing content (could be optional)
 - Add it to the components.xml setup

Outstanding questions:

 - Does it work well with portal_factory?
 - Does it give any noticable overhead (looks OK to me)?
 - Is it using Zope 2.10 or Zope 2.9's local component registrations
(should be easy to fix up anyway)?

I then think we should consider getting the catalog to do two things:

 - Add an object_implements index. I know the one that does any
"adaptable-to" interface from membrane is a bit slow, but one that
just indexes the names of zope.interface.providedBy(obj).flattened()
should be quick.

 - Add the intid from five.intid as an index and metadata. This allows
cross-referencing between the two.

I'd rather we get this in now so people can start depending on it,
than see lots of half-baked unique-object-reference-and-lookup
implementations (e.g. plone.app.redirector is very dependent on the
path of an object at the moment, since it can't assume the UID catalog
is reliable for all content). It looks to me like it'd be fairly low
risk, the only iffy thing being reindexing existing content on
migration if necessary.

Martin