Open SamCarlberg opened 5 years ago
Personally, I'd just like to lower the barrier to allowing users to contribute their own components.
What's the advantage of plugins vs encouraging contributions?
Community members adding new OpenCV operations is fine and welcome.
I just don't like the idea of "big" features from other organizations being added to GRIP and having us maintain it (or leave it to bitrot) - like custom code generation for Limelight (https://github.com/LimelightVision/GRIP) or Jevois cameras. I think that's better left as separate projects written and maintained by those organizations.
Fair enough.
Here are some things I'd like to propose around whatever API we expose:
EventBus
.One of the risks I see is, Tom and I had an incredibly hard time ensuring that GRIP was deadlock free. Something about the infrastructure that we designed made it particularly easy to cause deadlocks between the EventBus and the JavaFX render thread. This was a constant source of headaches. There may be better ways to resolve these issues universally (Kotlin coroutines come to mind but we don't want to add a dependency on Kotlin without a larger discussion).
What kind of resources do you have to dedicate to this? I don't have many, unfortunately.
I agree with all your points. Integration may be difficult - it'd probably mean using the event bus for many more things, but that makes it difficult to keep internal things internal since anything can see what's happening on the event bus.
I don't have a lot of time to work on this at the moment. But getting this out here at least gets it on the radar for future work.
Considering how several organizations are forking GRIP to add custom behaviors (Limelight, Jevois), it would be beneficial for us to provide a plugin API that third parties can use to add functionality to GRIP while not having to keep a fork and releases up-to-date.
Plugins should be able to provide:
Plugins would be developed as standard Java projects, dependent on the GRIP core project. Plugins that provide custom data types may need to also depend on the UI project for providing custom previews or socket controls. Code generation may need to be pulled into its own project so plugins won't have to have a dependency on the entire UI project.