Github user ellisonanne commented on the issue:
https://github.com/apache/incubator-pirk/pull/93
A few other comments for discussion:
First, I am not opposed to having separate ResponderDrivers for each
responder, but let's think it through and see if we really need to go down that
path.
I think that that main concern with having a single ResponderDriver vs.
delegating the ResponderDrivers to each responder is the bloating of the main
CLI and ResponderProps. Other than keeping the CLI/Props under control, I can't
see a particularly good, material (i.e. not stylistic) reason to delegate now
that we are rolling in a ResponderLauncher.
The ResponderProps can go ahead and be delegated down into the specific
responders independently of whether or not the ResponderDrivers get delegated.
The ResponderLauncher for each responder can be responsible for implementing
the 'validateResponderProperties' method that is currently in the central
ResponderProps - since the CLI loads the properties from the properties files
into SystemConfiguration, it will not require passing anything extra to the
launchers.
One design alternative to breaking out into specific ResponderDrivers
(which I am not opposed to BTW) would be to only allow the core properties in
the main CLI and force everything else to be specified via properties files.
This is somewhat limiting in some (contrived) cases that I can think of, but it
would allow for a main CLI and prevent the bloat since responder-specific CLI
options would not need to be added to the main CLI.
Thoughts?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
