• View
• Edit
• History
• Print

AccessorJSDevelopment

This page is obsolete

• AccessorJS - main page

AccessorJS Development

This page will aggregate information about AccessorJS development. It will describe some of the aims behind the project and information about who might be working on those aims.

Meetings

The AccessorJS working group will meet on ??? at ??? every ??? week(s). (This is yet to be determined).

Syntax Aims

The Accessor specification has evolved significantly since its initial version was defined. One of the aims of this project will be to bring the library into sync with the Ptolemy host, using Ptolemy as the reference point for the current state of Accessor syntax. However, there are other syntaxes that may be developed and prototyped in this library. In particular, we need to develop a syntax for the construction and communication of Actor graphs. This will be both used to write graphs, as well as communicate them between platforms. For instance, an Accessor model developed in Ptolemy, using its GUI, can be deployed into a NodeJS environment. If all of the constituting Accessors can be loaded into both platforms, their assembly into a model can be specified by this syntax for graphs.

Items

• Construct new loader for the current Accessor syntax specification.
• Design a syntax for Graphs.
• Get serializing and loading graphs between Ptolemy and AccessorJS working.
• Look into developing syntaxes for types, contracts, and other features.

Typing Aims

At the moment, the type specification for Accessors has been left to a collection of simple types recognizable in Javascript and Ptolemy. It would be a great advantage for Accessors to utilize a sophisticated type system that encodes structured data, facilitates abstraction through polymorphism, supports higher-order types such as function and Actor types, encodes constraints or contracts, and that integrates type ontologies. This type system can even prototype improvements to the type system in Ptolemy II.

Once a type system is designed and developed, how it is imposed and implemented is something that needs to be determined. At the present, AccessorJS has a thrown together type checker that can do runtime checks on various objects. When and how to impose these checks is something that requires some thought. Data, such as tokens, can be validated at runtime in the execution of Accessors, but composition can also be checked at design time when validating a model before it is executed. What about polymorphism? This all needs to be discussed.

Items

• Design type system.
• Determine how to use typing.
• Design and implement type syntax and representation.
• Write type checker.

Semantics Aims

One of the most important elements of Actor-oriented design (Actor as in Ptolemy Actor) is the variety of Models of Computation (MoC) that can be used to determine the semantics of model execution. The ramification of this multiplicity of semantics is the possibility of developing models with heterogeneous semantics, having different MoCs determining semantics at different hierarchical levels. Although there is an intuitive interest in using the Discrete Event (DE) MoC as a central model for Swarmlets, it should, in principle, be possible to design Swarmlets in other MoCs with different kinds of scheduling, varying degrees of synchronization, and various systemic constraints that may confer behavioral guarantees. To this end, I have already implemented a couple "Directors" in AccessorJS. Although the DE might be the most desirable, I first wrote a static scheduled Director and a Synchronous Reactive Director. Work needs to be done here to both write other Directors and to determine how this should generally be done. I have followed some of the idiosyncrasies of Ptolemy with regards to Receivers, but there are details to be hammered out regarding the way to do this cleanly in a Javascript platform.

Items

• Determine which MoCs to develop and how each of their semantics work in the platform.
• Determine how to decide which Accessors can participate in each MoC. What requirements should they fulfill? What interfaces should they implement?
• Look into the relationship between typing and MoCs.
• Determine the interfaces for Directors, Receivers, etc...
• Write Directors.

Platform/Infrastructure

At the core of AccessorJS is a utility library aimed at making development with the library cleaner and easier to reason about. I wrote this library to replicate a lot of the functionality in libraries such as ""underscore.js"" and ""prelude.ls"". I did not opt to use existing libraries because both the goals are different for their development, and to make AccessorJS as free standing as possible. There are other modules for dealing with module loading, object mixins, specialized data structures, and other elements of the current system. In principle, some of these should be made available to develop Accessors themselves.

Items

• Review and design platform libraries.
• Modularize libraries correctly, integrate typing, and make available to accessors.
• Design architecture of the system.

Contact/Participation

The primary contact for this effort is Chris Shaver at """shaver (at) eecs (dot) berkeley (dot) edu""". Email me with questions or interests regarding the project. For those who can edit this Wiki feel free to edit or update it with information.