Incorporation of 3rd party products into ROOT


Goals of the Investigation
Goal was to attempt to understand how easy or difficult it is to use 
various types of "3rd party products" together with ROOT, determine how
much of the functionality of the products would be available in a ROOT 
environment (or conversely how much of the ROOT functionality would be 
available in the 3rd party environment), and discuss possible ROOT 
upgrades to better support use of outside products.  In particular we 
talked about outside class libraries, outside graphics or visualization 
packages, and outside scripting languages.  In certain of these areas 
there was clear overlap with the groups looking specifically at CINT 
and at visualization; the specific technical issues are described in 
more detail in the reports of those groups.

Areas of Concern
* Outside class libraries:
1) Making transient use of outside C++ class libraries that do not need
 to use ROOT I/O or ROOT RTTI is already possible.
2) If you want to make classes persistent: must modify header file to
 inherit from root TObject class; use ClassDef macro for yourClass; 
 also need to put ClassImp macro in .cpp file
 then run rootcint -f MyClassDict.cxx .. .. .. (list of header files)
 (limitation on rootcint about level of macros: only 2 levels)
 which makes the Dict file for you; then everything is done 
 automatically, and you have both persistence and use in cint and from 
 root gui (as well as getting automatic documentation)
3) Use of the ClassDef and ClassImp macros is only necessary of you 
 want to use ROOT I/O and object browser; to quote from the ROOT web 
 page on Adding your Own Classes to ROOT:
 "If you are only interested in interactive access to your classes via 
  the command line or macro processor you do not need to use the 
  ClassDef and ClassImp macros."
4) At the moment interactive classes cannot be derived from compiled
 classes.  This is a serious limitation that the ROOT team would like 
 to fix.
5) There is a limitation on the classes that you use with ClassDef as
 described in (2) above.  In particular, CINT must "understand" the 
 header file of your compiled class (it does not need to understand the
 full implementation file).  This requires CINT to be upgraded so that 
 it can parse (but doesn't need to execute) STL and templated classes 
 (this is the same issue that D0CINT needs to parse DOOM files).  Can't
 have reference to exceptions or other obscure C ++ in the class \
 headers.
6) If you do not have access to the source code for the header files the use
 of the class library in ROOT will be limited.

* Graphics packages:
Root graphics is based on an abstract base class TGXW which already has
 two different implementations (one for X11, one for Windows).  In 
 principle there can be other implementations based on other graphics 
 standards.  In fact the original version of ROOT was based on MOTIF 
 and was able to deal with the required MOTIF callbacks so that ROOT 
 and MOTIF could both be active at the same time.  this feature has 
 been dropped; right now you can invoke a motif window and play with it 
 but ROOT wil be asleep until motif exits; this functionality could be 
 restored, or the same thing could be done for OpenGL callbacks, but it
 is unclear if this is necessary.
You can also use ROOT functionality as a library instead of immediately
 invoking the CINT interpreter, and could then make use of much of the 
 ROOT functionality (such as ROOT I/O) inside another environment (for 
 instance from within an OpenInventor application), but the 
 proliferation of APIs might be too confusing for the user.
In general there is an issue of who is in charge of the "event loop", 
 root or the graphics package.
See the visualization report for more details.

* Scripting languages:
Here too ROOT uses an abstract base interpreter class, so other 
 interpreters could be used, but this is trickier due to the 
 interconnections between CINT and the rest of ROOT.  You would also 
 want to insure that the interpreter gave access to the user's C++ 
 objects and methods, and it is not clear how to do this easily in JAVA
 or Python.  See the CINT report for more details.

Recommendations to Address the Areas of Concern
The improvements needed in this area are addressed in the CINT and 
graphics reports.  The only change that might be considered unique to 
this area is the CINT enhancement to allow inheriting from compiled 
classes, and it is not clear how complex a task this is or whether it 
can be accomplished in isolation from other CINT work.