I don't quite understand -- so there *are* root level elements specific to Zope that need to be copied into a Zope-over-ZEO environment? (hm, how do those elements get into a non-FileStorage Zope-over-ZEO environment?) And do those elements interfere even a little in a non-Zope-just-ZEO environment? The only way I can imagine, other than simplistic name clashes would be if a full iteration of such a ZODB would cause unghosting of objects lacking Zope .pyc and raise unnecessary exceptions. I ask because I'm trying to decide whether two ZEO RPMs are needed re ZEO-wo-Zope-2.0-1.i386.rpm and ZEO-w-Zope-2.0-1.i386.rpm, or just one. Somewhat similar to how the Zope RPMs have separate ZServer and PCGI flavor packages. -Jeff Rush Casey Duncan wrote:
It is only there due to lack of time to take it out. We had planned to take it out for 2.6, but time was never made to replace it with code to bootstrap an empty storage with the proper root level elements still residing in Data.fs.in.
-Casey
On Wednesday 13 November 2002 02:22 pm, Jeff Rush wrote:
Working on updating my ZOPE and ZEO RPMs I got to wondering...
What's in the default data.fs that ships with Zope? I mean, ZEO (actually ZODB) auto-creates a data.fs when one isn't found, so why does Zope come with one?
Or if there -is- something Zope-specific in data.fs, then shouldn't there be a warning in the ZEO notes that when ZEO is used _underneath_ Zope, be sure to copy the data.fs that comes with it?
My experience has always been with ZEO and StandaloneZODB, not ZEO+Zope so I'm puzzled.
-Jeff