search

WPIRoboticsProjects / GRIP

Program for rapidly developing computer vision applications
http://wpiroboticsprojects.github.io/GRIP
Other
376 stars 108 forks source link

GRIP should have a plugin API #917

Open SamCarlberg opened 5 years ago

SamCarlberg commented 5 years ago

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.

JLLeitschuh commented 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?

SamCarlberg commented 5 years ago

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.

JLLeitschuh commented 5 years ago

Fair enough.

Here are some things I'd like to propose around whatever API we expose:

  1. If we are exposing GRIP internals to users, we should try to hide access to constructors where possible and replace those uses with static factory methods.
  2. We need to clearly describe how to use the EventBus.
  3. We need to expose an API for cleanly integrating new components using Guice.
  4. We should coordinate/better define what parts of GRIP are part of the public API and what parts we want to keep entirely internal.

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.

SamCarlberg commented 5 years ago

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.