Replies: 1 comment
-
One relevant use case for this is described here: #9065 (reply in thread) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I originally described this functionality in #7459 (comment) and I think it will be relevant for #9066 and what I described in #9065 (reply in thread). I'm copying what I posted in #7459 (comment) here so we can discuss it:
I've thought of two approaches. We could support both or just the first one as it may cover everything we need for now... not sure.
A: Interface-based Plugins
Basically, we take the current SDK interface concept which registers interface names and implementations in the
InterfaceRegistry
and allow interface types to implement services.Let's take
x/gov
proposalContent
an example. If we converted the currentHandler
to protobuf that might look like:The
upgrade
module might register itsContentHandlerServer
implementation like this:And the server might be implemented something like this where the
Content
is pulled off theContext
using a specialsdk.GetPluginTarget
method:Then the
gov
module could callContentHandler
s by creating aContentHandlerClient
with agrpc.ClientConn
created with a specialPluginTarget
method:Authorization
Now for security purposes, we would need a bit more authorization around which modules can call plugins and which types can have plugins defined.
Maybe we would start with associating a service type with an interface name in the
InterfaceRegistry
:So then only types which are registered as
Content
implementations can have aContentHandlerServer
and we can ensure that only one server is registered per type.The
gov
module should probably also register itself as a "plugin client” for theContentHandler
service meaning it can callContentHandlerClient
s:And probably in the module manager we would need to authorize the
gov
module as a plugin client too:We may also need to authorize modules as plugin servers or we can simply ensure that only the module that registered the type can register a service against it.
B: Address-based Hooks
Address-based hooks would work pretty similarly, except that a module address would be the plugin target. So we’d have something like:
So basically with this approach we could directly call another service knowing its module address. This may be useful if there is any need to dynamically call methods on other modules at runtime without knowing which modules those are at startup. It may be possible that we can handle all our current use cases with Approach A for now though.
Beta Was this translation helpful? Give feedback.
All reactions