...
While searching for the perfect IEnergyCorr, we finally break the obstacles by using a kind of "proxy" class which were centralizing all the access to the TDS and Gaudi services. We called it the "kernel". As a side effect, centralizing all the Gaudi-like access stuff has considerably reduced the rest of the code and made it clearer. Since kernel was to be shared by all algo-like objects of the package (let's call them "actors"), we made it a Gaudi tool, and we put the code to access this tool in a CalReconActor class to be inherited by all actors. This is what is described below. And this is what is more or less the current state of the code.
I must say I am still not glad enough with this. For example, CalClustersAlg enforce the use of one clusterinfg algorithm as the first one. In the case of a complex reconstruction which alternates cal and tkr steps, it does not make sense to redo the clusters from the beginning each time, does it ? Why not make everything a simple Gaudi algorithm and use a typical simple Gaudi structure such as below ?
For each kind of job, the user can very freely require the best sequence of algorithms in his job options. Whatsoever, I want to keep the kernel made before, which proved very useful, so I would prefer :
If you worry about the fact that a user can also freely and easily makes an irrelevant sequence of actors, there are several answers : you can provide good job options examples, or even enforce the use of predefined job options. We could also go one step further with some classes whose role is to setup the validated sequence of actors. I call them "kits", as shown below. That can be seen as the replacement for "CalClustersAlg". Also, such a top level actor could prove necessary to enforce the right order of initialize calls (we must ensure that the kernel initialize is done before the one of actors which use it).
