Edward's June 19, 2015 email

What I am envisioning for accessors is a registration mechanism like that used for node (NPM) and Vert.x modules. Accessor names should be globally unique, and a directory of accessors should be maintained as it is for node and Vert.x modules.

A separate registration mechanism will be needed for modules supported by each accessor host. The host-independent part of this is the module name and the API (signatures of the functions in the module). The module implementation itself (the function implementations) can be host dependent.

What we have now is:

A. For the first of the above, https://ptolemy.berkeley.edu/accessors
This is very crude. It is flat (no hierarchy, clustering), and putting things in the repo are only handled through svn commit.

B. For module APIs, https://ptolemy.berkeley.edu/accessors/wiki/Version0/OptionalJavaScriptModules
This is also very crude. This page gives informal descriptions of the module API.
A better way to specify a module API would be to provide a prototype for the module that documents each function and provides a host-independent implementation of each module (e.g., throw an exception). Then each host-specific module should use that at its prototype and override the functions with host-specific implementations.

C. For host-specific module implementions: $PTII/ptolemy/actor/lib/jjs/modules I don't know where the host-specific implementation is for node.js or browser hosts.
I'm not sure we have working node.js or browser hosts right now, as many things have changed.

We could clone ptolemy-independent repos in the ptolemy tree, if necessary, e.g. to have a local copy of A and B.

This really needs to be worked out sooner rather than later. The most stuff we build with an inadequate layout, the more trouble we will have creating the right layout.

NPM
Back to Notes

AccessorRegistration

Edward's June 19, 2015 email