Minutes of the Event Data Model Working Group Meeting
                                  16 March 1999
                                   Rob Kennedy,
                for the CDF Run II Event Data Model Working Group


Attending: Rob Kennedy, Rick Snider, Liz Sexton-Kennedy, Chris Green,
           Jim Kowalkowski, Marc Paterno, David Waters, Farrukh Azfar
By Video:  MIT (Betsy Hafen)
By Phone:  Berkeley (Paolo Calafiura)


I) Event Data Model Prototype - Rob Kennedy

	Rob K presented a draft version of his talk EDM Prototype to be
given at the 17-Mar-1999 Offline Meeting. For the final version, see

http://www-cdf.fnal.gov/upgrades/computing/projects/edm/slides/EDM_update_19990316.ps

	There was confusion over the roles of the ObjectIdManager and the
StorableObject in my example. The EDM prototype will be changed to store
something other than an IdManager in the EventRecord (an distinct instance of
which is used by the EventRecord... hence the confusion). Rob K simply was
taking a short-cut to get any StorableObject class to be stored, and is
planning anyway to have the IDManager be no longer a Storable Object and to
save its state in a separate object (IdManagerState) which is a
StorableObject. 

	There was a mild preference for Id to have an undefined value == 0,
minimum defined value == 1, and be implemented by an insigned int.

	It was asked that if ObjectIds will be used in the Begin-of-Run event
as well, where links to the Module Parameter Sets are maintained, will there be
a collision of Ids? Links from Event data to Module data are made with distinct
identifiers though, ModuleId and AbsParmSetId. At worst, one must interpret the
identifier to know into which domain it "points", event data, module data,
calibration data, etc.

	If more than one IdManager stores its state in an EventRecord, how can
we differentiate between them when restoring state? Of course we use the oid of
the IdManagerState object. Some unique supervisor object which contains the
IdManagerState oid needs to save itself in the EventRecord. For instance,
EventRecord will save a EventRecordState object containing any internal data
members required to fully save/restore its internal state, such as HashTables,
IdManager, etc. Only the EventRecord can make use of its State object.
Meanwhile, a TrackCollection object might save the oid of the IdManager doling
out TrackIds... or perhaps an overall TrackingState object can be used. As long
as the supervisor object is unique, there should be no problem with using
multiple little aids like IdManager.

	Marc P. pointed out that the Calorimetry Review in progress may be an
even better testing ground for the Edm, better than Tracking that is, because
that code is in need of attention and is data structures are relatively
simpler. Rob K. had no objections, though did not want to drop using the CDF
Track and friends as a testbed as well.

	Several means of decoupling Offline classes from ROOT I/O interfaces
were discussed, focussing on the application of the Adapter pattern.

.the end.