CbmRoot » Framework

Question here: do we have are can imagine to have different algorithms for this task (extracting digis around a
trigger time and creating a CbmRawEvent)? If not, we do not necessarily need a base class.

Good question. I tend to see base classes as something that should be implemented as the need for them arises, i.e. at the earliest together with the second instance of classes that will derive from them. That way, the shared properties of the respective objects are clear from the outset and don't have to be predicted in advance. Also, doing it this way doesn't lead to states of the code that contain "unused generality", which some clean-coding paradigms suggest avoiding.

Basically, the argument against unused generality is a combination of "you probably won't need it" i.e. "accurately predicting future needs is hard", "it will confuse the users" and "it leads to higher code complexity without gains in functionality".

I would say the same thing about a base class for trigger / seed finding algorithms, by the way.

One prime reason for base classes is of course to implement common functionality. The second one, however, is to be able to start the framework integration before the concrete implementation is available.

The trigger is a very general concept - actually, it is the core of the online data processing, and there will be many different and differently complex triggers. The digi-based trigger (seed finder) is only one and a rather simple example. Already here, we are discussing different implementations (fixed window size vs. minimum number of digis).

Ok, sounds good. I see that all of the tasks that were assigned to me are marked as blocked by some other task. I will wait for this to be cleared.

@Volker Friese: Is the description of this issue still valid? Should CbmRawEvent be used or CbmDigiEvent?

The same question should be answered for https://redmine.cbm.gsi.de/issues/2263

RawEvent is mistyped, I of course meant the new class CbmDigiEvent.

Since the task is so generic, I am almost done with an implementation. Dominik, could you attend to #2266 instead, to avoid parallel work?

Ok, I will do that