It seems that it's the same idea as the ResponderLauncher with the service
component added to maintain something akin to the 'platform'. I would
prefer that we just did away with the platform notion altogether and make
the ResponderDriver 'dumb'. We get around needing a platform-aware service
by requiring the ResponderLauncher implementation to be passed as a CLI to
the ResponderDriver.

Am I missing something? Is there a good reason to provide a service by
which platforms are registered? I'm open...

On Mon, Sep 19, 2016 at 8:28 AM, Tim Ellison <> wrote:

> How about an approach like this?
> The "on-ramp" is the driver [1], which calls upon the service to find a
> plug-in [2] that claims to implement the required platform responder,
> e.g. [3].
> The list of plug-ins is given in the provider's JAR file, so the ones we
> provide in Pirk are listed together [4], but if you split these into
> modules, or somebody brings their own JAR alongside, these would be
> listed in each JAR's services/ directory.
> [1]
> src/main/java/org/apache/pirk/responder/wideskies/
> [2]
> src/main/java/org/apache/pirk/responder/spi/
> [3]
> src/main/java/org/apache/pirk/responder/wideskies/storm/
> [4]
> src/main/services/org.apache.responder.spi.Responder
> I'm not even going to dignify this with a WIP PR, it is far from ready,
> so proceed with caution.  There is hopefully enough there to show the
> approach, and if it is worth continuing I'm happy to do so.
> Regards,
> Tim

Reply via email to