Minutes of PASREC/ROOT Alternative Data Models Meeting
            ------------------------------------------------------

Meeting date: Monday, Sept. 14, 1998
Present:  Rene Brun, Irwin Gaines, Scott Snyder, Vicky White, Qizhong Li,
          Wyatt Merritt, Lee Lueking, Herb Greenlee, Jim Kowalkowski, 
          Mark Fischler, Pasha Murat.

1.  Using ROOT and D0OM together.

The first part of the meeting was devoted to a discussion of the possibility
of using D0OM and ROOT together.  The goal of a possible ROOT and D0OM 
combination is to develop a file format (probably the current ROOT format) 
that can be accessed through the D0OM I/O interface, as well as through cint.

2.  Using ROOT as an I/O back end for D0OM.

First we discussed the possibility of using ROOT as an I/O back end for 
D0OM.  Such an idea is natural for D0OM, which was designed to accomodate 
alternative I/O mechanisms.  Using the current version of ROOT, this could 
only be accomplished by copying D0OM data to ROOT data (d0_Object to 
TObject), similar to what is now done with DSPACK.  Also, for the resulting 
ROOT file to be readable by cint, it would be necessary to convert D0OM 
style headers to ROOT style headers.

3.  Can the ROOT and D0OM object models be merged?

As the above procedure does not seem very convenient, there was some 
discussion of what it would take to merge the D0OM and ROOT object models.
This would allow a single set of headers to be used for both D0OM and ROOT,
and would make the intermediate copy step unnecessary.  

Currently, there are three differences between the D0OM and ROOT object 
models.  First, D0OM and ROOT use different base classes: d0_Object and 
TObject.  Second, D0OM uses (primarily) STL containers, whereas ROOT uses 
its own non-template containers.  Third, D0OM uses both smart pointers 
(d0_Ref<T>) and bare pointers, whereas ROOT only allows bare pointers.  
With respect to the second difference, Rene Brun said that the ROOT 
developers are already committed to supporting STL containers.  In fact,
Rene Brun expressed interest in borrowing Scott's STL adapter code for use 
in rootcint.  With respect to the third difference, Rene Brun indicated that
it might be possible to add some kind of smart pointer class to ROOT as 
well.   With respect to the base class issue, the possibility of using 
TObject as a base class for all D0 persistent classes was discussed.  The 
simplest way to do this would be to derive d0_Object from TObject.

4.  TObject issues.

One potential disadvantage of deriving d0_Object from TObject is the 
physical coupling issue.  How much ROOT code would be pulled into all D0 
executables?  After the meeting Scott Snyder did a test where he compiled 
and linked a simple program with a simple TObject class.  The result was an 
executable with a size of 11.5 Mb drawn from 274 source files, i.e., a 
significant fraction of all ROOT code.  The same test with d0_Object gave 
an executable size of 50 kb drawn from five source files.  It is clear that 
for deriving d0_Object from TObject to be feasible, some work would have to 
be done to decouple TObject from the rest of the ROOT system.

5.  Database issues.

The second part of the meeting was used to discuss the issue of supporting
databases in ROOT.

6.  The ODL problem.

One problem that is common to both ROOT and D0OM is the ODL (object 
definition language) issue.  ROOT and D0OM both use C++ headers to define 
their persistent classes, which they parse using cint.  However, C++ headers 
are not well suited to defining a database schema.  In the general case, one
may want to define the database schema independently of the C++ class.
Thus, one needs two ODLs, one for C++ and one for the database, or at least 
more general ODL than C++ headers.  We in D0 (mainly Vicky White) have been
thinking about this problem for some time.  Rene Brun said that the ROOT 
developers were also aware of the problem.  So far, this remains an unsolved
problem for both teams.

7.  Abstract I/O back ends for ROOT?

The database discussion lead into a discussion of whether ROOT can support
alternative I/O formats, as D0OM does.  The answer appears to be yes, but 
not currently.  In the case of ROOT, the way one does this is to use TBuffer
as an interface base class, from which alternative I/O mechanism can be 
derived.  In fact ROOT already does this to implement multi-buffered I/O for
TTrees.  However, ROOT has not thus far taken the step of making the TBuffer
interface completely abstract.  Currently, TObject creates instances of 
TBuffer using the new operator (and thus is physically coupled to the 
TBuffer implementation).  Abstracting the TBuffer interface would provide 
the benefit of a) reducing the coupling of TObject to the ROOT I/O 
mechanisms, and b) making alternative I/O mechanisms selectable at link or 
run time without recompilation.

8.  Database queries.

Vicky White pointed out that the I/O interface provided by TObject is not
general enough to support database operations, such as queries.  We 
discovered the same thing in D0 while we were developing the D0OM I/O 
classes.  This led us to invent a database I/O class, d0StreamDB, which 
extended the standard D0OM I/O interface class, d0Stream.  Rene Brun also 
recognized this, as he had earlier said that certain ROOT developers were 
working on an SQL database interface (class TSQL).

Herb Greenlee