Mailing-List: contact dev-help@nifi.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@nifi.apache.org
Message-ID: <BLU436-SMTP217FD918460214120FFB8E4CE7D0@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: [DISCUSS] Extraction of Extension API
From: Mark Payne <markap14@hotmail.com>
In-Reply-To: <CAJQrPiTy0QKfWNzJ7G=4QbyuiYYLjM_9Ue-Kd_UA81CpVxUGGg@mail.gmail.com>
Date: Fri, 6 May 2016 16:18:03 -0400
Content-Transfer-Encoding: quoted-printable
References: <CADT6bVs-UmqARD4YBSPKK4CnvtqryW1poFhDV12tmN8pj6b=2A@mail.gmail.com> <CAJQrPiTy0QKfWNzJ7G=4QbyuiYYLjM_9Ue-Kd_UA81CpVxUGGg@mail.gmail.com>
To: dev@nifi.apache.org
archived-at: Fri, 06 May 2016 20:18:17 -0000

I'm a +1


> On May 6, 2016, at 3:46 PM, Brandon DeVries <brd@jhu.edu> wrote:
>=20
> +1.  Seems like a good idea, and now is a good time.
>=20
> Brandon
>=20
> On Fri, May 6, 2016 at 3:31 PM Aldrin Piri <aldrinpiri@gmail.com> =
wrote:
>=20
>> All,
>>=20
>> 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.
>>=20
>> 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).
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20