+1. Andy LoPresto alopresto.apa...@gmail.com PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Mar 11, 2016, at 9:41 AM, Mark Payne <marka...@hotmail.com> wrote: > > +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 >>>> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
