THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Recent commits have allowed us to create extensions with code and dependencies that can be included conditionally. This will allow MiNiFi C++ consumers to select the features that they desire. The next step is to move functional components into this paradigm.
The first component will be processors. There has always been a small selection of base processors within MiNiFi. Moving these to a separate extension will allow consumers to include processors conditionally. The design of this extension will be specialized to allow processors/or controller services to be selected in groups or individually. Further, these selected components will be built within the executable and as a shared object that can be versioned as a deliverable to MiNiFi agents. This will be integral to the update framework that will be discussed shortly.
If a consumer wishes to create a binary with only a GetFile processor and an RPG, they could specify the following flags (subject to change):
cmake –DINCLUDE_ONLY=GetFile –DINCLUDE_ONLY=RemoteProcessGroup.
This approach will create a binary with only the GetFile processor and RemoteProcessGroup along with a shared object. The shared object will include a version that identifies the built source and enables agents that load that shared object to enforce update rules. While a binary limited to GetFile and an RPG may not be useful to many, including updates to either can allow us to update agents in real time through the transmission of a shared object.
The next focus will be components within MiNiFi such as C2. Creating build time conditionals for these components will facilitate the eventual goal of making libminifi more developer friendly. The code is created in such a way that modularization is simple; however, we don’t have compile time capabilities to exclude integral components to an agent. Further, we don’t have an API that is intuitive. This proposal includes the foundation for that API. The goal will be to use CMAKE to more easily facilitate building either a library or agent.
While MiNiFi C++ can create bindings for virtually any language we recognize that not everyone wishes to use C++ or some component libraries that make bindings simpler. As a result, there will be C functions that facilitate the usage of LibMiNiFi. In doing so we can seamlessly create bindings for any language without the need for libraries that may not be desired across platforms. The current projection is that we facilitate compartmentalizing components. All functional components can and should be programmatically linked with the ability to have some or non. For example, if a consumer simply wants to transmit files across site to site. The following functions will facilitate this( subject to change):
int8_t create_flow_file(FlowFile** flow_file, char *content_location, size_t size) int8_t transmit_flow_file(FlowFile *flow_file, char *nifi_host); int8_t free_flow_file(FlowFile *flow_file);