[Zope-Coders] Data.fs.in -- relic?

[Matthew T. Kromer]

"Pinky, are you pondering what I'm pondering?"

"I think so Brain, but if we got rid of all these outdated ornaments, 
what would we put on our Christmas tree?"

Data.fs.in is a relic.  The reason I say this is because we go through 
all the effort in DB creation to populate an EMPTY Data.fs; so why do we 
have Data.fs.in?  It would seem that the purpose is to allow you to have 
differently populated databases depending on whether you grew from a 
stock Data.fs.in or switched storages (or blew your Data.fs away without 
re-running wo_pcgi.py. )

To me, that doesn't make much sense.

In OFS/Application.py, in the initialize method, various efforts are 
taken to ensure that the Application object has certain objects in it.

I'd rather see some of this logic broken out somewhat, so that 
Data.fs.in goes away (maybe we have a placeholder file in its stead to 
hold open the directory for CVS checkouts).  In the initialize method, 
all of the various fixups that should take place to the ZODB should be done.

Icing on the cake would be if the initialize method could detect forward 
migration of the database; such that it could add new objects 
one-time-only, since some of the objects are sticky, and some aren't (ie 
a new database might be populated with some defaults like QuickStart, 
etc, wheras an upgrade would not try to put it back if it had been deleted.)

An alternative would be to have something like a cookbook script that 
could make a Data.fs.in.

I bring this up because as I created my own version of Data.fs.in for 
Zope 2.5 with Session Tracking, I looked at the log file and there was a 
brief history of all the various things that are likely to happen with 
Data.fs.in that could go wrong (ie it needs to be packed so there is no 
undo log, etc etc).  That got me to thinking about "are 
standard_page_header and standard_page_foooter going to get replaced for 
new installs?"