At 07:23 PM 1/6/00 +0000, Jim Fulton wrote:

If anyone wants to work on this, I'd be willing to set up a mailing list and provide advice.

Please do. :)

Some issues:

- How to handle references accross databases. At a basic level, this is not too hard, but...

- How to handle garbage collection in a multi-db environment. Oops. Storages are currently responsible for GC. This won't account for references from other databases.

- How do databases get connected, from a UI point of view. Do you get to specify a database when you add an object? Any object? Where do databases get defined?

One idea I just thought of would be to have a databases area of the control panel where one could add database objects that modeled root database objects. Then, perhaps one would do the moral equivalent of a link from an object in one db to another.....

- .... There are probably other issues I haven't thought of.

The work Ty and I are doing (and which we'll be talking about at the conference) is asking all the same questions. However, we're not really interested in making it all automagic by the system, we're more concerned with establishing a pattern framework for making storage issues like these transparent to code at the problem-domain level. Specifically, we want to be able to write ZClasses whose instances neither know nor care what databases (relational, LDAP, or ZODB) they or the objects they relate to are stored in. We do this by delegation in a standardized framework, where certain objects have responsibility for creating, finding, or storing instances that meet an abstract interface. These "Implementor" objects are environmentally acquired, and thus what database a thing should be stored in (not to mention what class actually is instantiated) is seperated from an object's specification of what kind of thing it wants to relate to. We haven't yet given much thought into how this could be made fundamental to the existing Zope framework; we've been more treating it as a layer of practices for applications built on Zope. But it might be interesting to re-examine such scenarios as "folder adds an object" under our model as an instance of the scenario, "instance asks an Implementor (of abstract type ManageableZopeObject, let's say) to create an owned instance of an object and return a storable reference." (Note, by the way, that we are not yet treating abstract types as being quite so concrete as the fascinating Interface system you've implemented. We are viewing them more as loosely defined plug-in points within a framework, where Implementors provide a spot for someone integrating different products to add the necessary glue.)