Deprecated: JANA/DANA

JANA Home Page

http://www.jlab.org/JANA

Future development

Here are some thoughts about what things should be put into JANA or how it's current design should be changed. I am starting this to hopefully be a list of things that can be done later since I don't have time to do them right now.

1. Default Factory Choice: After usiing the framework a bit, it has become clear that it would be nice to be able to specify the "default" factory for a given data type once and have that used everywhere. The way it is now, if I want to use a tagged factory for a certain data type, I have to create a configuration parameter and have every place that accesses the factory use that configuration parameter. There should be a way to tell the framework to use a specific tag if the request uses an empty string (default) for the factory tag.
2. JException/jLog: Standardize exception and logging classes.
3. Replace HDCLASSDEF with virtual method in JObject.
4. JANA namespace: Place JANA inside a namespace. Let's see, what should we call it ..mmmm.....Oh yeah, "JANA"!
5. Geometry info: Some code was written to help with getting geometry info, but it needs to be revisited and completed. As of right now, folks have started putting geometry info into special factories. The geometry info is really a different type of data than what the factory mechanism is designed to do. This also needs to be tied in to the hdds system. This may entail adding a generic object storage mechanism into JApplication such that an object pointer is stored along with a valid run-range and can be retrieved by any factory of any thread.(??)
6. Out-Of-Band Factory Data: One thing discussed some time ago is how to access data on macro-scale from a factory in addition to the micro-scale data obtained through the normal factory mechanism. The specific example was how to access residual energy in a calorimeter that does not appear in any of the clusters a factory produces. This can currently be achived via the factory pointer, but maybe there should be a more formal mechanism to access a single object that holds this type of data. (??)
7. const correctness: Methods should be reviewed so that if they do not change internal object data, they should be declared const methods.
8. Vertex Object: Create an object to hold the event vertex. For now it can be set to the center of the target, but later we can use tracks to help pin it down. This vertex object should be used by all reconstruction code instead of hard coding the center of the target.
9. Warn/Crash on auto factory generation: Maybe code should, by default, crash when a user asks for objects that don't exist instead of auto-generating factories. A command line option can be used to bypass this behavior.