Better Plugs Imagined

Our plugin api has emerged through many experiments. Here we consider what has or hasn't worked and what we might want in the future.

Read About Plugins as they are currently built.

The Factory plugin offers a menu for creating new plugins. It can also identify appropriate plugins based on dropped contents.

Better: The menu should be divided into columns based on categories already in the plugin metadata.

Better: The available plugins should interact with the Factory so as to help dispatch dropped content to the right plugin. Translation of representation should happen in the plugin, not the Factory.

Servers publish a client-side plugin for a given type from a directory by the type name.

Plugins can assume some services like jQuery. They can also load their own with wiki.getScript().

Better: Plugins could build dependencies in with browserify.

Better: Plugins could share resources loaded from public CDNs. These could be cached via manifest with fall back to origin server.

Plugins generate dom content from story items handed to them. This was envisioned as emit($item,item) generating the view and bind($item,item) connecting the view to event handlers. At one time the emit could be omitted if the dom elements were constructed by the server.

Better: When many items are generated at once, all emits should be completed before any binding starts.

Better: Both emit and bind passes should be partially serialized such that plugins can reliably look left for collaborators.

Plugins look left for data. Although there is primitive search support in wiki.getData() newer plugins implement dom based protocols of their own. github

Better: Plugins should all advertise the availability of data they have using some notation inspired by radar-source and sequence-source annotations.

Better: Centralized support for finding and updating data sources should be realized independent of the dom.

Better: Centralized support should be provided for finding and reevaluating consuming plugins when values or configurations change.

The Method plugin (at least) offers an eval method that can be used for off-screen computation. The Reduce and Rollup plugins (at least) exploit this for off-screen computation.

Better: Computations should be expressed as dynamically generated javascript programs that can be optimized by the JIT compiler.

Better: Core should be disciplined about error forwarding using the node.js conventions.

Core plugins module attempts to catch errors from emit/bind of plugins. This fails when callbacks break traceback to the try/catch. github

Plugins contain pages of documentation that includes sample applications, markup conventions and links to the source repositories with their corresponding communities.

Servers may provide a /system/plugins.json endpoint that returns a list of available plugins.

Better: The factory plugin menu should include a "more" function that consults the plugins.json and constructs a ghost page listing all plugin about pages.

Better: Plugins should carry semantic version numbers. Items should know the versions that created them. Version incompatibilities should be detected and updates facilitated.

Plugins hold data that they understand. They should therefore represent that data to other federated wiki services that want to know what they do.

Better: The synopsis held in a sitemap should understand what words are visible and what aren't. The Paragraph plugin knows this as it interprests [ ... ] links.

Better: Side by side diff could highlight changes to visible words. But what would we expect when the changes are to configurations where the words are used to guide some other visible process?