- edited description
create a plugin system
with go's static linking behavior, investigate the following options:
- create a process-based plugin system using rpc to communicate
- use
cgo
with an external C-based lib that embeds mruby or lua to allow writing plugins in a dynamic language
REFERENCES:
Comments (13)
-
reporter -
reporter - edited description
-
reporter - edited description
-
Perhaps is worth taking a look on how Packer (from the creator of Vagrant) does the plugin architecture:
-
reporter Thanks. I also like what I've seen on Packer, but haven't jumped into the source yet.
My current thinking is that a three-tiered structure that allows users to write plugins in lua or mruby would be cool. Uru (or rather uru_rt) is one process, a separate plugin manager process (Go) with an embedded lua/mruby runtime is the second process, and plugin lua/mruby source files is the third piece. Uru_rt and the plugin mgr communicate over rpc.
My preference is to enable users to easily write plugins and not have to compile Go exes. Not that building Go exes is difficult, but writing lua/mruby plugins is much nicer.
I'm hoping to find time to spike up a prototype to see how things would work. At this point, I'm open to multiple approaches but want any solution to be end-user friendly.
-
reporter TODO: carve out time and look at mattn's go-mruby project that embeds mruby into go.
I like the idea of fewer moving pieces, but this cgo solution likely means the end of cross-building for all 3 platforms from windows.
Look again at if/how mruby deals with filesystem stuff. Can't remember if it doesn't provide FS support, or now has a gem, or ???
-
reporter I'm becoming less convinced by the argument that plugins should be written in lua or mruby. I don't find the assumption that writing plugins in Go and having to perform a build cycle is overly difficult or a barrier to adoption.
Plugins will be written in Go.
The focus is now to create a plugin manager integrated into the
uru_rt
exe and developing a plugin manager API and a plugin API. -
reporter - marked as major
-
reporter - edited description
-
reporter KEY QUESTIONS:
- Enable via explicit configuration or via autodiscovery from a
plugin
subdirectory touru_rt
's dir? - To keep CLI responsive, only enable plugin of interest rather than all in
plugin
subdir? - Plugin implements only 2 functions:
init
for initialization, andrun
to execute?init
must include anidentify
-like capability that injects the plugins help info into the main help structure.
- Enable via explicit configuration or via autodiscovery from a
-
reporter Plugin API, usage, and development issues to be documented in the plugin wiki page.
Comments, feedback, and suggestions to the plugin dev wiki page should be tracked in this issue.
-
reporter Go 1.5 will add initial support for Go-based shared libraries as summarized in May's state of Go
I much prefer implementing plugins via shared Go libraries rather than current idea at plugin wiki page
-
reporter Based upon Go Execution Modes the
-buildmode=plugin
looks interesting. There appear to be a few kinks: not all platforms will be supported, the go-based plugins must be built with the same version of go I builduru_rt
with forcing plugin recompiles when I make newuru
releases, and I currently see no support for theplugin
build mode in the go source.Skipping go plugins for the time being; focus on the CGI-like plugin API.
- Log in to comment