[DISCUSS] Changing core components of MiNiFi to support compartmentalization

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Changing core components of MiNiFi to support compartmentalization

Marc Parisi
Hi,
   I've put together a proposal [1] and would like some feedback before I
begin these changes. The goal is to support a more fluid API experience
with the addition of C function calls to interact with libminifi. The goal
of this article is to discuss some initial steps to getting a usable API
from the build target we have known as libminifi.

I would love to hear any feedback. If we take this route we open the door
for many people who want the externalized C lib; however, a C interface to
C++ may not be for everyone.

Should we simply provide a C library or is this good enough for everyone?
These are questions that I ask to the community so we can make an informed
decision.

I've laid out a few pros and cons. Performance degradation, real or
imagined, will surely be the biggest con anyone can lay out, but would
appreciate more input in the comment section of the proposal.

  Thanks,
  Marc

[1] https://cwiki.apache.org/confluence/display/MINIFI/
LibMiNiFi+Design+Proposal
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Changing core components of MiNiFi to support compartmentalization

Andy Christianson-3
Marc,

Thanks for putting this design doc together. Here are some thoughts:

- Multiple INCLUDE_ONLY statements is internally contradictory. If we go this route, we should allow INCLUDE_ONLY to take a list.

More broadly, I think we need to uniformly support either a white list or a black list of features. In master right now, it is more of a blacklist (you DISABLE what you don't want, everything ENABLEd by default). Given the nature and purpose of minifi, switching to a whitelist (ENABLE everything you want included; everything else is DISABLEd by default).

Instead of INCLUDE_ONLY, I think we should have a simple, consistent ENABLE_* cmake interface. To make this a little less brutal on end-users, we may want to borrow existing package management ideas, such as groups (denoted here with an ENABLE_ALL_<X> pattern):

- ENABLE_ALL_CORE_PROCESSORS
- ENABLE_ALL_ARCHIVE_PROCESSORS
- ENABLE_ALL_USB_PROCESSORS
- ENABLE_ALL

Enabling a group would enable everything under it. For the user who wishes to include everything, a simple catch-all ENABLE_ALL would be provided.

Regarding the public libminifi interface, I think we should provide two: libminifi.so/libminifi.a libminifi++.so/libminifi++.a. The C-interface would be the lowest-common-denominator, and the ++ (c++) interface would just publicly expose the relevant classes as they exist.

Given libminifi is currently C++, if we stick with that internally, the C interface should just wrap and translate the C++ interfaces/objects and hopefully not add additional constraints or complexity to the internal design. If our aim is to support environments where only a C compiler is available, then there needs to be a very clear delineation in the code base of where C begins and C++ ends.

Regards,

Andy I.C.

Sent from ProtonMail, Swiss-based encrypted email.


>-------- Original Message --------
>Subject: [DISCUSS] Changing core components of MiNiFi to support compartmentalization
>Local Time: November 9, 2017 10:54 AM
>UTC Time: November 9, 2017 3:54 PM
>From: [hidden email]
>To: [hidden email]
>
>Hi,
> I've put together a proposal [1] and would like some feedback before I
> begin these changes. The goal is to support a more fluid API experience
> with the addition of C function calls to interact with libminifi. The goal
> of this article is to discuss some initial steps to getting a usable API
> from the build target we have known as libminifi.
>
> I would love to hear any feedback. If we take this route we open the door
> for many people who want the externalized C lib; however, a C interface to
> C++ may not be for everyone.
>
> Should we simply provide a C library or is this good enough for everyone?
> These are questions that I ask to the community so we can make an informed
> decision.
>
> I've laid out a few pros and cons. Performance degradation, real or
> imagined, will surely be the biggest con anyone can lay out, but would
> appreciate more input in the comment section of the proposal.
>
> Thanks,
> Marc
>
> [1] https://cwiki.apache.org/confluence/display/MINIFI/
> LibMiNiFi+Design+Proposal
>