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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to