>=========================================================== > > >We don't see the problem. People who want a different graphics back-end >use ROOT in "batch" mode,which will only load the "dummy" ROOT graphics >abstract base class TVirtualPad to resolve some unsatified symbols in >other parts of the system. From there on one can use any third >party graphics package, get a pointer to a ROOT object (histogram) >and draw it. At most we have to make sure that there are the >right "getters" to get the necessary info out of the object. >During the meeting yesterday, I mentionned how the interface >to utilities like X3D and OpenGL were implemented. Connecting >OpenInventor could be realized in the same way. If this requires >a slight modification in the TCanvas or TPad classes, well, let's >discuss this point. Probably, it will take less time to implement it >than to discuss if it can be done. > >Idem for the I/O part. The pure ROOT I/O part is currently extremely >light (TFile, Tkey, TBuffer and the individual Streamer functions). You >will always get them but you don't have to use them. Because they are >light there is not need to decouple them via an abstract base class >like is done with the graphics system. If you want to use, e.g., Objy >just make for the ROOT classes you want to store persistent adapter >classes (like BaBar is doing) and store those in Objy. Just pretend >the ROOT I/O is not there. > >In case one has not noticed it yet. ROOT and Java developement both >started in the beginning of 1995. Although both systems were >independently developed the designers shared the same vision: >to make a complete, coherent, easy to use, OO framework. >The Java developers decided they needed a new language to support >their ideas, the ROOT team decided that C++ plus a C++ interpreter >(offering the essential RTTI capabilties missing in C++, but available >in Java) would do. Look closely at both systems and you see remarkable >similarities (TObject vs Object, Streamer vs Serialize, TClass vs >Class, GUI, network classes, etc.). Still nobody talks about taking >the Serialize functionality out of Java so one could use an OODB. >Or to take out the AWT to interface to a different graphics >package.It is not necessary because all these things can easily be done >by just implementing them and ignoring the alternative (default) >functionality provided by baseline Java. So also with ROOT. On the >otherhand, if you don't like Java (other than for its performance) you >probably also will not like ROOT. > > >So, for us it is basically out of the question to start breaking things >apart in separate independent projects. They are not independent. >In all these discussions, one should not forget the essential goal of >the project: data analysis and visualisation. This means access to data >in several formats, histogramming, fitting and most of the time simple >2-d graphics. This also means an efficient scripting language and >a powerful GUI with an automatic interface to the users classes. >Graphics is an important element, but only one element among many >others. And, we repeat, if you simply want to use only the Root I/O, >you will not link with the graphics subsystem. > >We discussed with Guy Barrand during CHEP. We invited him to >collaborate with us. We believe that the main obstacle to a >collaboration is the lack of discussion on the important point >of "framework versus component-oriented software". >On the other hand, collaborations on the kind of projects we are >talking about imply a clear identification of the tasks and >clearly defined milestones. Technical problems, in general, >are easy to overcome. On our side, we will be happy to discuss >suggested improvements, new features, or modifications of classes >if it is shown that the connection of a new system is difficult. >This is clearly in the interest of our project. > >Rene &Fons > > > > > > > > > >Jeff Kallenbach wrote: >> >> Rene - >> >> On closer inspection it looks as though the lower level data management >> parts of the code (RIO, if you will) are closely coupled with the display >> part. This is why, for example, the user can edit resources from the >> canvas or from the command line. >> >> What seems to be needed for us to be able to add a different upper layer >> (vis) is to break the RIO off into a separate project, concentrating on >> OODB-like functionality. In particular, all display functionality (Draw, >> Print, Paint, ...) should be removed from this module. Of course this >> would also require re-engineering of the ROOT upper-level display code. >> The advantages of this would be as follows: >> >> The lower level (RIO) could be replaced by users who have lots of money >> to buy Objectivity or whatever >> >> The users could also plug in their favorite upper level (OpenInventor, >> SoFree) or use the ROOT display as it is. In the case of OIV/Hepvis, we >> would be able to develop a SoRIOAction... to interface with the data >> management part which is agreed by all to be superlative. >> >> Different upper levels could be attached as they become available >> (Java/Explorer/...maybe even things like MATLAB) >> >> This work could be done in parallel, and the individual pieces >> developed/maintained/distributed by interested parties - real >> collaboration with people doing a good job on their own interests. >> >> The ROOT vis as it is now will still be present, so that you and Fons >> can continue to develop on that. It just would be a separate module. >> >> I have spoken with Guy Barrand, who agrees that such a re-engineering would >> allow ROOT to grow more rapidly because of the collaboration it would >> inspire. He has hinted that in such a situation he would wish to join and >> provide help not only on the OPACS/Wo/OIV/Hepvis side, but also consult >> with his views on the RIO side - on the use of OODB for HEP. >> >> Give this some thought. I am supposed to come up with manpower estimates >> for the re-engineering and, if you think it can/should be done, I would >> welcome your input on how much time it would take. >> >> Cheers, >> Jeff >> >> =========================================================================== >> Jeff Kallenbach | Fermi National Accelerator Lab | Graphics, X Windows >> V: (630)840-2210 | jeffk@fnal.gov | F: (630)840-2783 >> =========================================================================== >