nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Bende <bbe...@gmail.com>
Subject Re: [DISCUSS] Extraction of Extension API
Date Fri, 06 May 2016 20:34:38 GMT
I like it +1

On Fri, May 6, 2016 at 4:18 PM, Mark Payne <markap14@hotmail.com> wrote:

> I'm a +1
>
>
> > On May 6, 2016, at 3:46 PM, Brandon DeVries <brd@jhu.edu> wrote:
> >
> > +1.  Seems like a good idea, and now is a good time.
> >
> > Brandon
> >
> > On Fri, May 6, 2016 at 3:31 PM Aldrin Piri <aldrinpiri@gmail.com> wrote:
> >
> >> All,
> >>
> >> I would like to propose a refactoring of the nifi-api for our master/1.0
> >> branch.  In summary, a lightweight and concise view of this module
> allows
> >> for reduced footprint of the NIFI API for components and minimizes the
> >> creep of those items that authoring components do not need to use.
> >>
> >> In a broader context there is a core set of interfaces that users will
> >> interface with in their generation of new extensions for NiFi.
> Summarily,
> >> these components have comprised Processors, Controller Services,
> Reporting
> >> Tasks, & Prioritizers (the last of which is currently under discussion
> to
> >> potentially be removed from this forward facing status).
> >>
> >> What I would like to suggest is the refactoring of the nifi-api module
> to
> >> be broken down into to two components: the nifi-api and the
> >> nifi-framework-api.  nifi-api will encompass all things developers would
> >> need to provide extensions tailored toward interacting with dataflow.
> >> nifi-framework-api would address the more internal items that are also
> >> extensible, but not something that is typically implemented and would
> >> consist of the remainder of those items not in nifi-api.
> >>
> >> This enables a core set of APIs that extensions can implement with a
> >> broader perspective of providing API compatibility between both NiFi and
> >> MiNiFi.  This enables some nice reuse of work with the goal ultimately
> >> amounting to, write for NiFi, run on MiNiFi and the reverse.
> >>
> >> Logistically, for NiFi extension writers, at first glance, not much
> would
> >> change with their efforts.  The core dependency would remain the same,
> but
> >> would be curtailed in its scope to only what is required.  Framework
> >> components of course, would need to be updated to include a dependency
> on
> >> nifi-framework-api.
> >>
> >> Given that the new structure would not yet be released, and to allow
> MiNiFi
> >> to continue on its development path, a Git submodule or subtree would be
> >> introduced into MiNiFi and supporting documentation on how to make use
> of
> >> this for those not familiar.
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message