Skip to content
Robert de Forest edited this page Jan 28, 2019 · 1 revision

Module interface

A module is something which can be invoked as a function. The first parameter of that function is a dimension locator. How that module installs itself is up to the existing core. The rest of this document is a proposal for the first scheme (FinchCore 0.0.1).

Returned by "require('module')(injector)"

An object with the following properties:

doesVersion(wanted)

Returns true if this module conforms to the expectations fo clients of the wanted version.

version

Returns a string describing the version implemented by this module.

Injector passed to require

  • Is a function taking a name and optional version
  • Returns a promise for a reference to the requested dimension/module

Rambling

Suppose we were to ignore the entire npm registry and think about the simplest way we could possibly capture and convey behaviors. We could come up with a schema which represents an installable module...

See coreUtils.yaml for an example.

Supposing coreUtils.yaml's contents existed in a server we'll call Alice, and supposing Bob's server wanted to install this module, Bob might pull the module via alice/api/behaviors/1234. This might produce an object whose .package looked like the data in coreUtils.yaml. We'll call that .package data coreUtils. Next Bob's server could inspect coreUtils.packageCommands.install.code and see that it's a string. To convert it to code Bob's server would look at coreUtils.meta.defaultCompiler and see 'coffee-script'. Bob's server would then known to use require('coffee-script').eval(coreUtils.packageCommands.install.code) to turn the string into a JavaScript function. And then Bob's server could invoke it.

Clone this wiki locally