create a plugin system

[Jon]

with go's static linking behavior, investigate the following options:

1. create a process-based plugin system using rpc to communicate
2. use cgo with an external C-based lib that embeds mruby or lua to allow writing plugins in a dynamic language

REFERENCES:

• http://eli.thegreenplace.net/2012/08/07/fundamental-concepts-of-plugin-infrastructures/
• http://eli.thegreenplace.net/2012/08/24/plugins-in-c/

[Luis Lavena]

Perhaps is worth taking a look on how Packer (from the creator of Vagrant) does the plugin architecture:

https://github.com/mitchellh/packer

http://www.packer.io/docs/extend/developing-plugins.html

[Jon]

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.

[Jon]

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 ???

[Jon]

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.

[Jon]

KEY QUESTIONS:

1. Enable via explicit configuration or via autodiscovery from a plugin subdirectory to uru_rt's dir?
2. To keep CLI responsive, only enable plugin of interest rather than all in plugin subdir?
3. Plugin implements only 2 functions: init for initialization, and run to execute? init must include an identify-like capability that injects the plugins help info into the main help structure.

[Jon]

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.

[Jon]

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

[Jon]

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 build uru_rt with forcing plugin recompiles when I make new uru releases, and I currently see no support for the plugin build mode in the go source.

Skipping go plugins for the time being; focus on the CGI-like plugin API.