1. Jon
  2. uru
  3. Issues
Issue #8 new

create a plugin system

repo owner created an issue

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


Comments (13)

  1. Jon 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.

  2. Jon 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 ???

  3. Jon 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.

  4. Jon reporter


    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.
  5. Jon 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 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.

  6. Log in to comment