[DISCUSS] Extraction of Extension API

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Extraction of Extension API

Aldrin Piri
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.
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Extraction of Extension API

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

Brandon

On Fri, May 6, 2016 at 3:31 PM Aldrin Piri <[hidden email]> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Extraction of Extension API

Mark Payne
I'm a +1


> On May 6, 2016, at 3:46 PM, Brandon DeVries <[hidden email]> 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 <[hidden email]> 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.
>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Extraction of Extension API

Bryan Bende
I like it +1

On Fri, May 6, 2016 at 4:18 PM, Mark Payne <[hidden email]> wrote:

> I'm a +1
>
>
> > On May 6, 2016, at 3:46 PM, Brandon DeVries <[hidden email]> 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 <[hidden email]> 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.
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Extraction of Extension API

Joe Witt
+1

On Fri, May 6, 2016 at 4:34 PM, Bryan Bende <[hidden email]> wrote:

> I like it +1
>
> On Fri, May 6, 2016 at 4:18 PM, Mark Payne <[hidden email]> wrote:
>
>> I'm a +1
>>
>>
>> > On May 6, 2016, at 3:46 PM, Brandon DeVries <[hidden email]> 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 <[hidden email]> 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.
>> >>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Extraction of Extension API

Matt Burgess
In reply to this post by Aldrin Piri
+1

> On May 6, 2016, at 3:30 PM, Aldrin Piri <[hidden email]> 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.