Deployd/Deployd — Issue #9: Plugin Interoperability and Sandboxing
Author: jeffbcross
Created: 2011-12-09 06:14:26+00:00
State: open
Labels: beta, feature

Should plugins just invoke methods of other plugins by require()-ing specific modules? Or should we add a layer of abstraction? Something like dpd.require(), which behaves similarly to require() but takes a unique plugin name instead of a path to a module. Benefits of abstracting:

* If a plugin uses multiple sub modules, but wants to keep modules private to the plugin, this could allow that.
* It would ensure that the user doesn't need any knowledge of the filesystem. Eg., if the filesystem hierarchy of plugins changes between API versions.

Plugins shouldn't need to deviate from the CommonJS module standard for the abstraction though. Perhaps whatever's attached to module.exports for the main file in a plugin would be public, and any sub modules would be private? For any of this to be effective, should we take measures to scope the use of require() inside plugins?

Conversely, plugins should should be able to broadcast global events, and listen for events on other plugins. Eg, when a user is poked, I should be able to listen for that in my gamification plugin so I can give them a "pokey" badge.