ksm-plugin-poc

Plugins, but for KSM!

Approaches considered (as of now)

KSM as a library

Refactoring and wrinkling out more parts of KSM to be utilized as a library altogether.

Advantages

• No "odd" concepts whatsoever, we'd depend entirely on Go constructs to make plugins work.
• Folks would implement a couple of interfaces and be well on their way.
• Demands a fairly larger amount of changes upstream.

Disadvantages

• No "on-the-fly" changes possible.
• No "pluggable" manifest injection possible.

Plugin as a binary

Compiling the plugin as a binary and extracting symbols from it.

Advantages

• Easy to implement.
• Pluggable injections possible.
• Does not require much changes upstream.

Disadvantages

• No debugging capabilities.
• No "on-the-fly" changes possible.

Plugin over g/RPC

Serving plugin assets over g/RPC endpoints.

Advantages

• "On-the-fly" changes possible, folks can reconfigure plugins to newer version and reload. KSM will pick up on the changes right away.
• Consequently, pluggable.
• Debugging possible.
• Does not require much changes upstream.
• Much more efficient way of sending marshalled data structures over-the-wire, owing to Protocol Buffers.

Disadvantages

• Comparatively more demanding in terms of complexity from the plugin side of things.