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.


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.


Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )

Reply via email to