I also agree with the removal of the stale/unmaintained components listed by Marton.
It would be nice if we could use a NiFi processor via JNI in a pinch if there is no native equivalent, until a C++ alternative becomes available. On the other hand, this does not work right now, it would be a lot of work to achieve it, and no user has asked for it. On balance, I would keep JNI for now, but I'm not strongly opposed to removing it. Thanks, Ferenc On Tue, Jun 11, 2024 at 7:15 PM Martin Zink <[email protected]> wrote: > > Hey Marton, > > I strongly support this, and I also agree with Gábor that JNI should > be dropped as well. > Minifi java is in a really good shape so if anybody wants to use the > java processors I can't see a reason why would they bother with the > C++ agent with JNI since the whole point of the C++ agent goes out the > windows (since you have to have JVM with all of its bells and > whistles), and since its not really maintained I don't expect it to > work that well anyways. > > And due to the unique nature of JNI implementation, I always felt like > that's the extension that hinders our refactor efforts the most > > BR, > Martin > > On Tue, Jun 11, 2024 at 6:29 PM Gábor Gyimesi <[email protected]> wrote: > > > > Hi Marton, > > > > I also support removing all of these unused extensions, thanks for > > starting the discussion about this! > > > > I think we could also discuss if JNI extension could be removed. It's > > a special extension for running Java processors in MiNiFi C++, but as > > MiNiFi Java is also available for this purpose, and I'm not aware of > > any users that are using Java processors in MiNiFi C++ maybe that > > could be removed as well. Similarly to the other extensions it hasn't > > been tested or maintained for years. > > > > Regards, > > Gabor > > > > On Tue, 11 Jun 2024 at 17:42, Arpad Boda <[email protected]> wrote: > > > > > > Marton, > > > > > > Thanks for bringing this up, I'm +1, too! > > > > > > Cheers, > > > Arpad > > > > > > On Tue, Jun 11, 2024 at 5:05 PM Joe Witt <[email protected]> wrote: > > > > > > > Marton > > > > > > > > I strongly support this. The path needs to be maintainable and keeping > > > > things around that dont get the love create many challenges. > > > > > > > > Thanks > > > > > > > > On Tue, Jun 11, 2024 at 7:48 AM Marton Szasz <[email protected]> wrote: > > > > > > > > > Hi community, > > > > > > > > > > We're considering to drop certain features from MiNiFi C++ that seem > > > > > to > > > > > be unused, and not worth maintaining. If you would like to keep some > > > > > of > > > > > them, please share your opinion and your use case for them! > > > > > > > > > > To be removed: > > > > > 1. CoAP C2: not used anywhere as far as I'm aware, and not well > > > > > maintained. C2 over HTTP would remain unchanged. > > > > > 2. nanofi: This was an initiative around 2019-2020 to rewrite about > > > > > half > > > > > of minifi in a C library form for integration to other software. There > > > > > was no development on it since early 2020, and I'm not aware of any > > > > users. > > > > > 3. pcap extension: not well tested or maintained, probably not used by > > > > > anyone > > > > > 4. usb camera extension: same as pcap > > > > > 5. sensors extension: same as pcap > > > > > 6. openwsman extension: same as pcap > > > > > > > > > > As we progress towards the new major versions, now is our best > > > > > opportunity to remove unused code, so the codebase becomes easier to > > > > > maintain, and this hopefully unlocks new feature possibilities. Let me > > > > > know what you think! > > > > > > > > > > Thanks, > > > > > Marton > > > > > > > > > > > > > >
