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: [email protected] >To: [email protected] > >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 >
