[DISCUSS] Extraction of Extension API

[Aldrin Piri <al...@gmail.com>]

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.

Re: [DISCUSS] Extraction of Extension API

[Matt Burgess <ma...@gmail.com>]

+1

> On May 6, 2016, at 3:30 PM, Aldrin Piri <al...@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.

Re: [DISCUSS] Extraction of Extension API

[Joe Witt <jo...@gmail.com>]

+1

On Fri, May 6, 2016 at 4:34 PM, Bryan Bende <bb...@gmail.com> wrote:
> I like it +1
>
> On Fri, May 6, 2016 at 4:18 PM, Mark Payne <ma...@hotmail.com> wrote:
>
>> I'm a +1
>>
>>
>> > On May 6, 2016, at 3:46 PM, Brandon DeVries <br...@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 <al...@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.
>> >>
>>
>>

Re: [DISCUSS] Extraction of Extension API

[Bryan Bende <bb...@gmail.com>]

I like it +1

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

> I'm a +1
>
>
> > On May 6, 2016, at 3:46 PM, Brandon DeVries <br...@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 <al...@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.
> >>
>
>

Re: [DISCUSS] Extraction of Extension API

[Mark Payne <ma...@hotmail.com>]

I'm a +1


> On May 6, 2016, at 3:46 PM, Brandon DeVries <br...@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 <al...@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.
>> 

Re: [DISCUSS] Extraction of Extension API

[Brandon DeVries <br...@jhu.edu>]

+1.  Seems like a good idea, and now is a good time.

Brandon

On Fri, May 6, 2016 at 3:31 PM Aldrin Piri <al...@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.
>