Phases in EventRecord Processing
                                   13 July 1999
                                   Rob Kennedy



	One of the issues that has cropped recently while discussing the design
and interaction of high-level physics objects is support for a more complete
set of phases in EventRecord processing. Currently we have a restore_links()
phase which occurs just after an event is fully read from disk. We should
consider adding more phases to support a wider variety of transient <=>
persistent representations for complicated classes. Discussions on the CDFTrack
class and the constraints placed on it by existing code indicate that enabling
a more complete separation of these representations is desirable. I propose
that we support the following phases with methods:

1) postread() - was called restore_links(). The more generic name hints that
other transformations may be made at this time. For instance, if a CDFTrack 
were to contain a Link<TRCK_Bank>, then it may convert itself from a Link to a
TRCK Bank to a CDFTrack with contained data members.

	Note that Streamer() was expected to be the place where all such
transformations occur. In some cases, however, the transformations require
knowledge of the contents of the event after all of the event has been read in
(such as restore_links()). Such must go into this separate phase.

2) prewrite() - conjugate to postread(). Called just before event is written out
to permit transformations to be made which require knowledge of the contents of
the event. Links do not require this phase, hence it was not inserted into the
EDM prototype.

3) store() - called whenever an object is stored in (appended to) the event.
Permits hierarchical object storage. A container by reference needs this if it
is to store its StorableObject data members when it itself is stored. A user
calling EventRecord::append() is assured that this call is passed down the
containment hierarchy to individual class store() methods. Most class's store()
methods would simply return(true).

4) restore() - conjugate to store(), called whenever an object returns a
ConstHandle due to a search of the EventRecord. A container by reference may
need this if it is to reconstruct the transient container of pointers from the
persistent collection of Links.

	I would like to add support for these phases to StreamableObject (an
abstract class). I have discussed with some the idea of creating another level
of base class (StorableObject has the above phases and a public destructor.
EventObject becomes what we now call StorableObject and has a protected
destructor. Only EventObject can be stored directly in the EventRecord), but do
not want to force that kind of change into the prototype until it is clearly
needed.

	Folks would have to rename restore_links() to postread() in their
EDM-compliant classes and add simple implementations of the other methods once
this change is made. Alternative suggestions for method names are welcome.

Thanks,
Rob K.