You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe we could decrease the number of decisions a plugin developer needs to do when using this SDK, by enforcing some conventions, and therefore simplify the process of creating your own plugin.
For example, the various NewGo... (e.g. sensu.NewGoHandler) require you to pass functions as arguments:
I believe by adopting some conventions on the name of these functions, we could reduce the number of arguments required and therefore the complexity. For example, if we assumed that a Plugin must adhere to a given interface, we could simply do the following instead:
Instead, maybe we could simply assume sane default values (e.g. I assume the Path and the Argument could be similar) but allow those values to be overridden for edge cases.
The text was updated successfully, but these errors were encountered:
One comment...
I don't think we always want to have an cmdline Argument backed by a path. The name of the path might be a convention we can set and have it match the argument name... but we will still need a bool to indicate if path override is desired.
Similarly with Env, we could enforce a naming convention but we'd still need a bool to enable/disable the optional Env binding.
Looking more closely... we actually could allow a PluginConfigOption with a Path but no cmdline argument set if we wanted to.
I believe we could decrease the number of decisions a plugin developer needs to do when using this SDK, by enforcing some conventions, and therefore simplify the process of creating your own plugin.
For example, the various
NewGo...
(e.g.sensu.NewGoHandler
) require you to pass functions as arguments:I believe by adopting some conventions on the name of these functions, we could reduce the number of arguments required and therefore the complexity. For example, if we assumed that a Plugin must adhere to a given interface, we could simply do the following instead:
Similarly, I don't believe declaring a
PluginConfigOption
should require that much attributes, e.g.Instead, maybe we could simply assume sane default values (e.g. I assume the
Path
and theArgument
could be similar) but allow those values to be overridden for edge cases.The text was updated successfully, but these errors were encountered: