History for MultipleSimultaneousStorage

??changed:
-
Proposal:  MultipleSimultaneousStorage

	Initiator:  "Jason Spisak":mailto:[email protected]

	This is really a carry over from the MultiFileStorage proposal
	that approaches the problem from another angle.  

        Jim -- I'm not sure what problem you're trying to solve. It
        seems you simply want to spread storage over multiple physical
        storage mechanisms.  Is that right? What if the storage as
        have different semantics? Should the resulting storage have
        the least common denominator semantics?

        Jim -- See MountedDatabases

	The **root**
	object in a ZODB is required.  This has to be creatively
	statified in order to allow multiple storages of any kind (
	RelationalStorage , FileStorage ) to be used together to form
	a coherent object hirearchy without modifying the ZODB.  The
	**root** object would be responsilbe for presenting the ZODB
	with a set of objects that looks like a single storage.  By
	separating the StorageManager from the ZODB you gain storage
	modularity, and the existing interface to the ZODB can remain
	constant.

    - Short Term Goal

	I have no idea how to accomplish this but, here it goes.  To
	have the **root** object of the ZODB come from another Python
	object, and not a hard coded element.  This middleman object
	hands the ZODB a standard Data.fs file.  The Python middleman
	object would be the StorageManager.

    - Medium Term Goal

	Have two the Data.fs become 2 files.  Split at an arbitrary
	location, and have the StorageManager merge the two before
	handing it to the ZODB.  Or even better, the StorageManager
	could know where to look for an oid in a registry of somekind.

    - Long Range Goal
	
	World Peace.

    - Final Goal
	
	Have multiple storages register themselves with the StorageManager, and provide a consistant set of objects to the ZODB.