...

On an abstract level, the statement "if Zope data can be accessed by other applications" seems to be a pretty clear violation of encapsulation, but that's just the object zealot party line. :^)

Allowing the IT guys to write ad-hoc reports against the data in the ZODB may be a showstopping requirement in some projects; integration with existing reporting tools would necessitate access via SQL.

I'd like to play devil's advocate here for a moment - can you give me an example of an application where ad-hoc reports on _Zope_ object data are a requirement? Why would you not use Zope's relational database integration tools (SQL Methods, etc.), to deal with this kind of enterprise data? That way any existing ad-hoc reporting tools that work with your RDBMS could be used.

We could view such requirements as a clarion call for another layer of (refactored) design: perhaps providing hooks to allow the Zope developer to tackle the OO<-->RDBMS mapping problem head on would be useful? I see these hooks as similar to SQL adapters, but in the service of persistence, rather than method invocation.

The real point of supporting an abstract data storage in Z2 is to let folks use a backing store that they feel comfortable with (as far as stability support, scalability, availability, etc.), rather than to try to integrate Zope into the relational (or even object/ relational) world. I'm a bit curious what those hooks would look like - I suspect that the more you think about them, the more there will need to be :^)

Breaking the dependency on pickling, using instead, say, XML stored as a blob, might be helpful in some circumstances, as well.

Is XML stored in RDB tables that much better than pickles? Are there (reporting, etc.) tools that support this, or is it just that XML would be slightly more human-readable? Note that I'm not necessarily against such a thing, I'm just curious what purpose it serves. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com