Proposed plugin RPC spec #24
Conversation
| // "content" or "data" for now | ||
| Kind string | ||
| // "text", "plugin_a", etc. | ||
| Name string |
There was a problem hiding this comment.
I think it might be good to add another string field here -- a namespace field. Using namespaced plugin names will allow users to use plugins from various providers. So the fully qualified plugin name would be <namespace>/<type>.<name> (see an example in #5). For our plugins the namespace can be blackstork.
The namespace only affects installation of the plugins, but not parsing / execution of the templates
There was a problem hiding this comment.
Done! This comment reminded me of an unspoken terminology choice I made. Since type is a reserved name in golang and also there are already a lot of different "types" floating around I started referring to the content or data as "block/plugin kinds" to separate them a bit from every other meaning of "type" I have to work with. It's pretty easy to find-and-replace "Kind" to "Type" if it's objectionable, but I kinda like the term "plugin kind" here.
|
If there are no further suggestions we can merge it! |
Hello! This is a proposed interface for the plugin system. Let's discuss and settle on this, it will allow some work in parallel since I kinda blocked everyone's work with my parser rewrite 😅