You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Andre <an...@fucs.org> on 2017/02/16 14:22:41 UTC

NIFI-329 - IRC Processors

dev,

I am starting to work on NIFI-329 and plan to soon introduce processors
capable of interacting with IRC servers.

At this stage I am looking to implement only PublishIRC, however, given the
processor will use a controller service this may be later on expanded to
handle IRC message consumption (i.e. ConsumeIRC) and perhaps bot type
functionality by mimicking the ethos of HandleHttpRequest and
HandleHttpResponse processors.

Since this is the first time I am trying to write a controller service may
I ask you some feedback about my first reading?

Currently the "best" ASL2 IRC library seems to be KICL (Kitteh IRC Client
library[1]) which happens to support IRCv3, SSL and a bunch of other stuff.

KICL Client class seems to fit very well within a controller service
onEnabled, but I have the impression its event driven API is not a natural
fit to NiFi processors and will require some work similar to the one
required to get ListenSMTP working properly.

Is this reading correct? In you experience, is it manageable or should I
look for another library?


Any feedback will be appreciated.


[1] -
http://kicl.kitteh.org/en/latest/#kitteh-irc-client-library-documentation

Re: NIFI-329 - IRC Processors

Posted by Matt Burgess <ma...@apache.org>.
I had looked around a while ago for IRC clients (was thinking of
contributing IRC processors as my first contribution to NiFi, but got
sidetracked), I agree that Kitteh seems like the best choice (others
like Pircbotx, JerkLib, and Martyr don't have friendly licenses).
They all seem to have one thing in common: being event-driven.  This
is not a bad thing and as you pointed out, you could implement it the
way some other processors do (by writing the flow files from the event
handler, or using a LinkedBlockingQueue or something to pass messages
between the event handler and the onTrigger method).

I too am working on a processor that requires an event handler, either
approach seems manageable, just a little different than "normal" NiFi
processors.  I say go for it!

Regards,
Matt

On Thu, Feb 16, 2017 at 9:22 AM, Andre <an...@fucs.org> wrote:
> dev,
>
> I am starting to work on NIFI-329 and plan to soon introduce processors
> capable of interacting with IRC servers.
>
> At this stage I am looking to implement only PublishIRC, however, given the
> processor will use a controller service this may be later on expanded to
> handle IRC message consumption (i.e. ConsumeIRC) and perhaps bot type
> functionality by mimicking the ethos of HandleHttpRequest and
> HandleHttpResponse processors.
>
> Since this is the first time I am trying to write a controller service may
> I ask you some feedback about my first reading?
>
> Currently the "best" ASL2 IRC library seems to be KICL (Kitteh IRC Client
> library[1]) which happens to support IRCv3, SSL and a bunch of other stuff.
>
> KICL Client class seems to fit very well within a controller service
> onEnabled, but I have the impression its event driven API is not a natural
> fit to NiFi processors and will require some work similar to the one
> required to get ListenSMTP working properly.
>
> Is this reading correct? In you experience, is it manageable or should I
> look for another library?
>
>
> Any feedback will be appreciated.
>
>
> [1] -
> http://kicl.kitteh.org/en/latest/#kitteh-irc-client-library-documentation