Reimplement the plugin system

[MD]

Add support for events to the plugin system, which will make it much more versatile than v5's one.

• Add plugin loading
• Add plugin construction
• Add core event manager setup (registering events and listeners)
• Add routes support (based on libs/express.js, passing a express#Router to the plugin to construct them)
• Add an event manager which emits events to plugins (see below)
• Migrate command routes and MC logging to use events
• Add APIs for authentication and sockets
• Probably something I forgot

Plugin Loading and Construction

Plugins will have to provide either:

• a single file (.js/.node) in plugins/,
• a module inside its own subdirectory in plugins/, or
• a file named index.js in the plugin's subdirectory.

For an example module, see plugins/sampleplugin.js.

Plugin Routes

When plugins are constructed (probably after they have all been loaded) an lib/plugin/api#API will be passed to them. They will have access to the plugin loader itself as well as helpful methods from the API class. This will allow them more freedom than v5's ref/route system allowed. (Compare this to libs/express.js.)

Events Managers

In libs/events.js there will be the event manager. Plugins will be able to listen to (and cancel some of) the events which the server fires. There will be a core event manager for NodeMC itself and an event manager for plugins to fire events (might be useful for inter-plugin communication).
Plugins can fire core events to control the server.

There will be three types of events - regular, one-time and final. By default, events will run asynchronously unless specified.

Planned NodeMC events

• log - Fired whenever Minecraft outputs to either stdout or stderr. Cancellable; if cancelled, message will not be logged to frontend.
  {text: "This is an error", type: "err"}
• command - Fired whenever a frontend or plugin tries to fire a command. Cancelable; if cancelled, command will not be sent to server.
  {command: "help"}
• start - Fired whenever NodeMC tries to start Minecraft (all starts including restarts).
  Cancelable.
• restart - Fired whenever NodeMC tries to restart Minecraft.
  Cancelable.
• stop - Fired whenever NodeMC tries to stop Minecraft.
  Cancelable.
• crash - Fired whenever Minecraft stops without NodeMC triggering it.
• auth - Fired whenever the frontend tries to authenticate. (This is not an authentication plugin API!)

(May fire events upon stage changes)

Stages to add

• Core event creation
• Core event attaching
• Plugin loading
• Plugin construction

See branch NodeMC/v6-events.

[Jared Allard]

Sounds good to me!

[MD]

I'm leaning towards just a .js with the plugin metadata in module.exports and the plugin class in module.exports.plugin.

<insert Plugin class here>
module.exports = {name: "Plugin Name", id: "Plugin unique ID", version: "1.3.2", desc: "Plugin description", plugin: Plugin}

@jaredallard @gmemstr What do you think?

[MD]

Okay, went with that, going to update issue accordingly.

[Jared Allard]

I know I'm late but that's a great way of doing it.

[MD]

Revised plugin system

These changes mostly reflect the removal of the stage and event manager mechanisms.

Add support for events a proper API to the v6+ plugin system, which will make it much more versatile than v5's one.

• Implement server manager for multi-server support (see #7)
• Add plugin loader
• Add plugin construction
• Expose API via a global (global.nmc?)
• Load plugins and execute in a separate VM (with vm.runInThisContext)
• Add interface for routing (like libs/express.js, passing a express#Router to the plugin to construct them)
• Add interfaces for server manager, auth and sockets (and loader?)
• Add an event manager which emits events to plugins (see below)
• Migrate command routes and MC logging to use events
• Expose interfaces through the server manager for each wrapper
• Fire events from individual components as needed (file access, server manager, maybe even CLI?)
• Probably something I forgot

Plugin loading and Construction execution

Plugins will have to provide either:

• a single file (.js/.node) in plugins/,
• a module inside its own subdirectory in plugins/, or
• a file named index.js in the plugin's subdirectory.

Plugins will have to provide a module in plugins/ in its own subdirectory, for example:

- <root>
  - lib/...
  - backend/...
  - frontend/...
  * plugins/
    * <plugin directory>
      * plugin.json
      * plugin.js
      * <any other files as desired>

For an example module, see plugins/sample/ (currently only on v6-plugins).

Plugin Routes

When plugins are constructed (probably after they have all been loaded) an lib/plugin/api#API will be passed to them. They will have access to the plugin loader itself as well as helpful methods from the API class. This will allow them more freedom than v5's ref/route system allowed. (Compare this to libs/express.js.)

Plugins will be executed in their own sandbox, with the plugin API exposed via a global. The API will expose separate interfaces for each component which will emit events and provide methods to plugins. These separate component interfaces will hopefully allow us to change the internals of NodeMC while keeping the plugin API the same.

Events Managers

In libs/events.js there will be the event manager. Plugins will be able to listen to (and cancel some of) the events which the server fires. There will be a core event manager for NodeMC itself and an event manager for plugins to fire events (might be useful for inter-plugin communication).
Plugins can fire core events to control the server.

There will be three types of events - regular, one-time and final. By default, events will run asynchronously unless specified.

Each component interface exposed by the API will fire events relevant to themselves - for example, the server manager could fire wrapperConnected and wrapperStopped events, and callbacks would expect err, wrapper arguments, while each Wrapper object could fire log, serverStarted, serverStopped etc.

Planned NodeMC events

• log - Fired whenever Minecraft outputs to either stdout or stderr. Cancellable; if cancelled, message will not be logged to frontend.
  {text: "This is an error", type: "err"}
• command - Fired whenever a frontend or plugin tries to fire a command. Cancelable; if cancelled, command will not be sent to server.
  {command: "help"}
• start - Fired whenever NodeMC tries to start Minecraft (all starts including restarts).
  Cancelable.
• restart - Fired whenever NodeMC tries to restart Minecraft.
  Cancelable.
• stop - Fired whenever NodeMC tries to stop Minecraft.
  Cancelable.
• crash - Fired whenever Minecraft stops without NodeMC triggering it.
• auth - Fired whenever the frontend tries to authenticate. (This is not an authentication plugin API!)

(May fire events upon stage changes)

To be decided for each component interface - the API itself is unlikely to be an event emitter.

Stages to add

• Core event creation
• Core event attaching
• Plugin loading
• Plugin construction

@gmemstr @jaredallard Thoughts?

[MD]

Closing, see #38 for further discussion