Replies: 4 comments 3 replies
-
I think we've briefly discussed this before, but I would love to get your thoughts on this @GuessWhoSamFoo and @mklanjsek |
Beta Was this translation helpful? Give feedback.
-
I really like that and feel that it will help us in many ways and especially to iron out the plugin interface! It would be great if we can at the same time reorganize the client code and pull out all components into separate library. That will help us in supporting the other frameworks and better internal separation on client side. Probably not part of this work, but still important. By doing both we would achieve more modular architecture and improve maintainability and extensibility. |
Beta Was this translation helpful? Give feedback.
-
Something to keep in mind is that overview and cluster overview may take advantage of concurrency that isn't exposed in the plugin interface. It's certainly possible to build both of these as plugins, but keep that in mind. |
Beta Was this translation helpful? Give feedback.
-
Also, think about links. There isn't a way to expose ownership of creating links for an object to a plugin without creating the link yourself. |
Beta Was this translation helpful? Give feedback.
-
Currently the modules we ship with Octant are compiled directly in to the Octant binary.
I think re-working these modules as plugins would provide some major benefits to the project and community. By doing this, the evolution of our plugin API would be directly tied to what is shipped in the Octant binary. This would also ensure that we are consuming and using our own expected public APIs, the same way any plugin author would have to (aka dog fooding), and since we would also have to build proper test harnesses to get these plugin modules under test, it would act as a forcing function to creating a better integration testing libraries.
Originally talked about in this issue: #1293
Beta Was this translation helpful? Give feedback.
All reactions