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 >>
