+1 from me as well
> On Mar 11, 2016, at 8:36 AM, Matt Burgess <mattyb...@gmail.com> wrote:
>
> I'm a +1 as well.
>
>> On Mar 11, 2016, at 8:26 AM, Tony Kurc <trk...@gmail.com> wrote:
>>
>> Should this be marked as a [VOTE]? In any case, I'm +1
>>
>>> On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri <aldrinp...@gmail.com> wrote:
>>>
>>> All,
>>>
>>> Didn't explicitly mention this, but was aiming for a lazy consensus [1] to
>>> continuing on with the outlined procedure. If no one objects in the next
>>> two days, will look at carrying out the prescribed items listed.
>>>
>>>
>>> [1] http://www.apache.org/foundation/voting.html#LazyConsensus
>>>
>>>> On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri <aldrinp...@gmail.com> wrote:
>>>>
>>>> NiFi Community,
>>>>
>>>> Originally discussed in January [1], the MiNiFi agent model was met with
>>>> positive feedback. I would like to propose a concerted effort toward the
>>>> execution on the ideas presented and establish a basis for incorporation
>>> of
>>>> the feedback received from, and collaboration with, the community to move
>>>> toward our goals of helping with dataflow from the point of its origin.
>>>>
>>>> To that end, I would like to propose the creation of:
>>>>
>>>> -
>>>>
>>>> a separate repository (nifi-minifi),
>>>> -
>>>>
>>>> establishment of a MiNiFi JIRA (MINIFI), and
>>>> -
>>>>
>>>> production of an associated feature proposals and design documentation
>>>> within our Confluence Wiki spaces beyond the initial points outlined
>>> by Joe
>>>> with some additional proposals architecture and roadmap
>>>>
>>>> The separate JIRA and Git repo map to the existing ASF infrastructure for
>>>> projects with similar efforts and will aid in a cleaner release and issue
>>>> management process.
>>>>
>>>> Central to the aims of MiNiFi, the tenets of its operation and execution
>>>> of dataflow are the same as NiFi itself: security, provenance, and
>>>> management of dataflow; helping bring information to NiFi while
>>> maintaining
>>>> the full extent of its provenance.
>>>>
>>>> Some clarifying points based on the discussion that existed previously:
>>>>
>>>> -
>>>>
>>>> While there may be reuse of NiFi components and some overlap, MiNiFi
>>>> is a separate effort that is complementary to but not necessarily
>>> directly
>>>> compatible with existing components and extensions. Obviously there
>>> has
>>>> been a lot of great effort which we can reuse, but in striving to be a
>>>> smaller footprint, we should not find ourselves beholden to the
>>> existing,
>>>> core, NiFi architecture.
>>>> -
>>>>
>>>> There will exist scenarios where there is an inherent need to go
>>>> smaller and closer to the source system. This will take the form of
>>> native
>>>> code that builds upon the same efforts and items originally developed
>>> under
>>>> the Java ecosystem.
>>>> -
>>>>
>>>> Design should take consideration of disparate execution environments
>>>> and provide ways to robustly handle varying means of communication and
>>>> exchange. Accordingly, communications both in management of agents
>>> and the
>>>> transference of data should be neutral to technologies, providing the
>>> same
>>>> flexibility and adaptation that allows NiFi to communicate with a wide
>>>> breadth of systems, protocols, schemas, and formats.
>>>>
>>>>
>>>> [1]
>>> http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html
>>>
