Since MiNiFi C++ requires completely new code (unlike the Java version), I don't see any reason we cant deviate where it makes requirement sense. If we move the provenance onto the flowfile, then your build issues and my stability issues can be simplified because the local provenance repo becomes log only and where the local repo could be handled by a standard logging mechanism instead. As you stated, installing additional open source libraries in production environments is a near non-starter.
If no one disagrees with the approach or really desperately wants to take it on, I'm ok with taking the action item to start working on a good transport structure and looking at making the changes needed for it to work through S2S. This also requires making changes to NiFi to allow for the provenance to be added to the main NiFi repo; this is something I was planning on doing anyway as part of a new enterprise dp/dg engine based on NiFi I'm working on. We need someone to test a reliable replacement for LevelDB (be that LMDB, which I believe comes standard in RHEL distributions, or whatever) and integrate it or convert the local repo to log only. I'll get to it eventually after I make the other changes if no one else does. -- View this message in context: http://apache-nifi-developer-list.39713.n7.nabble.com/MiNiFi-C-Data-Provenance-and-Related-Issues-tp14024p14040.html Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.
