My thought on this, is that you will be forced to explicitly consider the nature of this relationship and its storage at the application level. If you write explicitly for ZODB, you might use a BTree, for example. Or perhaps you'd have some kind of global container for the Tasks, with a Catalog to index them, and a method on TaskPerformer to query the Catalog.
How would you propose to map this to an RDMS? Well, substituting catalog queries might be relatively straightforward, but perhaps rather time consuming to develop in a generic way. The BTree might give you a bit more trouble. Probably you'd have to end up using some sort of generic queryable containers that translated to BTrees or Catalogs or RDBMS tables, depending...
And lo! You now have an application framework. Oops.
I'll try to somehow get your and Shane's opinions together a bit: I think Shane's approach does most of the job (of OR mapping) if the objects we are talking about are relatively simple and the application domain is relatively typical for what Zope can do well. E.g. the composite objects we have in mind for the groupware (user credentials coming from LDAP, rest in the ZODB, or file stored in the filesystem metadata in SQL DB, rest in ZODB) can easily be modelled this way. And the existing Zope API (manage_AddX, manage_changeProperties etc.) would do most of the job. But the problems start with querying. Can the ZCatalog do it? Does it make sense to implement a "SQLZCatalog" instead of just offering native SQL query objects or an abstract query language like SkinSkript? To put it simply: The reason why we want to develop a "framework" (or framework extension) is that the Zope framework just doesn't do the stuff we need yet. BTW, the reason why we didn't just use ZPatterns was very similar: ZPatterns makes it easy to write an abstract implementation of a project, but you still have to write all the "glue code" between the storage and the application layer by hand. What we want (and what TransWarp is about, with a slightly different focus) is that we can just map an attribute to a data source and all the glue code (either ZODB or SQL statements) is auto-generated. If the new "framework" just extends the existing Zope API, I don't see a problem. ZPatterns did not, but maybe it is just not that easy to do so (and not all parts of the Zope API really should bear this name ...). The really good thing about the whole discussion is that at the end we will see much better where we should put things. We (the SmartObjects people at iuveno) do not really want to have a completely new world of SmartObjects that will require a new API to learn. We just want to add new functionality to Zope, be it in the core or as mix-in classes, or through-the-web products. Joachim