Extend JOmniFactory-style interface to other JANA components

[DraTeots]

For the record, OmniFactories are completely broken for outside of PodIO cases and if one uses Parameter and not ParameterRef. I actually took OmniFactory code and made my own theme park such factory but without input-output tag names and idea of underlying independant algorithm+config struct for each factory. There are some other improvements.

Not to intersect with OmniFactoris I called it CozyFactory

Fun fact. "Cozy" sounds close to "Kozeey" which translates as "goat", which gives us The GOAT Factory

Working with the GOAT/Omni factories instead of usual JFactories:

Pros:

1. Much more fun and easier to handle
2. Like those declarations and use of things like values = m_whatever_input()
3. Even more like outputs streamlined m_my_output().push_back(result)
4. In real data apps where events might be different in terms what data is in, it is good to have fail-proof stub for when there is no input data.
5. I feel like such declarative declarations of factory needs are more clean in terms of general architecture

Cons:

1. Having hidden Process that catches exceptions and makes it harder to debug but that deserves a separate bug report for JException.
2. I feel like such declarative declarations of factory needs are not fully inline with the overal current JANA2 design

Thoughts:

1. After working with them you want such API to be consistent, firstable for Processors and EventSources level
2. With the current paradigm, IDK how much Parameters are extensible for users
3. I understand that both OmniFactories and CozyFactories are crafted for needs and designes of particular reconstruction software and creating such things on JANA2 level so that they are universal might be impossible. But the overal design pattern is good and plesant to use.
4. With 3 one at least can put it to examples.
5. How python would work with it?

[nathanwbrei]

What's wrong with Parameter? Can you provide a test case?

[nathanwbrei]

I'm working on upstreaming the omnifactory machinery (Parameter, Input, Output, Service, Resource) into JANA itself, uniformly across all components (EventSource, EventProcessor, EventUnfolder, JFactory, JMultiFactory)

[DraTeots]

It is rather difficulties with parameter management I foresee than bugs. And basically goes about how users would write their own Parameter classes. If they want to extend the functinality.

[DraTeots]

Ah, and maybe it is a good idea to add ExistingParameter that will utilize a parameter that is known to be used somewhere else. How same parameters should properly be handled between classes of the same plugin or between plugins? E.g. in FL4FPGA we have a a parameter number of SRS timebins, which should be provided for EVIO reader, DQM processor and GEM reconstruction. And it should be the same value to function properly.

[nathanwbrei]

Breaking this conversation down into actionable items so that I can close the issue someday:

• Improve exception handling in omnifactories and multifactories, delegating to a common mechanism
• Add ExistingParameter flag in order to escape Omni's strict namespacing
• Demonstrate using Omni's Parameter helper with custom types. Challenge mode: Types that need to be parsed several different ways, e.g. nthreads
• Deprecate JEventProcessorSequential and JEventProcessorSequentialRoot, demonstrating that 100% of their functionality is present in the Omni-fied JEventProcessor now.
• Make JFactory/JMultiFactory/JEventSource fully Omni-fied

[DraTeots]

Can we add this to examples in particular to PODIO

https://github.com/JeffersonLab/JANA2/blob/master/src/examples/PodioExample/PodioExampleProcessor.cc

[nathanwbrei]

Absolutely!