Nexus Meeting Notes 2016-11-04

From wiki.gpii
Jump to: navigation, search


  • Antranig
  • Colin
  • Simon


  • I created a "dashboard" page on the GPII wiki for tracking Nexus pages:
  • Update on Antranig's Nexus work
  • Update on discussions at Cyprus and potential work to make whole of AsTeRICS model component values available via API
  • Discovery

Upcoming milestones

  • Face-to-face Feb 2017
  • Be ready with what we want to show at the review in March
  • Review April 2017

Update on Antranig's Nexus work

Goal for review:

  • Connect to Nexus with browser-based client
  • View tree of Nexus components

Longer-term, working towards an authoring environment.

Curent work:


State that needs to be established by configuration:

  • Peers constructed
    • Peer component path
    • Peer grade name(s)
  • Model relay rules relating peers
    • Component paths of source/target peers
    • Model paths of source/target peers
    • Relay rules
  • WebSocket bindings between peers and external devices

Current process to establish above state:

The aim of the discovery work is to simplify or remove the work needed to establish a working configuration:

Use cases

  • A MIDI keyboard is plugged into a computer running a synthesizer
    • A UI is displayed offering options on how it should be configured
  • Someone brings a personal tablet into proximity with a kiosk -- the kiosk may be operated from the tablet [this was oringially an idea from Cloud4All and we would need to check with Gregg and Matthias to check and see if it would be suitable for a P4A demo]
  • => HELP <=

If we stick with music, could we integrate Tony's music work?

  • Music notation visualization
  • Highlights as you play the melody (maybe does not move on to the next note if you don't hit the right one)

Single switch sequencer

Mobile smart single switch that pairs with GPII enabled device.

We need to distinguish Nexus from AsTeRICS:

  • Discovery and auto-configuration

Demo idea: show Antranig's visualizer during discovery: see configuration being automatically added


  • --> The "co-occurence engine" will construct the peers. Relay could be either internal or external to the peer definition itself, since this will be a detail that can be configured in the "co-occurrence recipe specification"
  • --> "co-occurrence rules" will have a semantic/structural form a little as if they were kinds of RegExps targetted against the entire tree (thankfully we will express them as JSON to avoid the horrour that is PARSING)
  • ----> A kind of "prior art" in a kind of distant cognitive sense is the *SMIRKS REACTION TRANSFORM LANGUAGE* : P - in that this is a dialect expressing the possibility for co-occurrence of CERTAIN THINGS in which the result is the instantiation of OTHER THINGS
  • ----> Our situation isn't quite as complex as SMIRKS since we don't propose the destruction of the reactants (we will consider these immutable as most things morally are in Infusion), but nonetheless we will need some kind of cognate of "capturing groups" that will allow specific elements in the reaction products to bind onto particular elements in the reactants
  • How to know what types of things are connected?
    • Grade of peer?
    • Contents of peer model?
    • Some other component property?
    • A device registry that is separate from the peers? (device registry wouldn't contain relay rules or other details on device relationships)
  • --> Yes, there will be a device registry mapping "things which can appear on buses" to concrete peer definitions. As per our earlier discussion this will constitute a form of "device driver" for the things (e.g. looking up PCI hardware vendor ids, device classes etc.)
  • Is it possible to alter the model relay rules of an existing component?
  • --> not quite sure what is meant by "alter" but in terms of "at runtime", no. These rules are set up at construct time and torn down at destroy time. However, they can be overridden (if namespaced) by derived grades (Simon: yes, I was thinking "at runtime", thanks)
  • What about when things disappear?
    • How is disappearance communicated?
    • How are the peer relationships updated?
    • What about unreliable connections that come and go?
  • --> I imagine there will be "policy definitions" for which some defaults will appear in the device registry (e.g. "no reconnection for x seconds means destroy the peer") but which can be overridden by the user on some kind of class-based basis (e.g. a preference with respect to "communication over buses of a certain type" or with respect to (GPII) contexts - this will represent a standard kind of preference in the GPII ontology)
  • --> If any of the prerequisites for a "co-occurence rule" fail to be met (as a result of the peer being destroyed), the actions of the rule will be undone - that is, anything which it constructed will be destroyed

Longer term, we will want a "device driver" repository, which we could integrate with the QI.

Have a Design Crit for brainstorming use cases / demo ideas for the Nexus: explain discovery and what it will enable.

Peer constructed by device driver

Recipes that need particular types of things, would have holes where concrete components are placed -- a "holder" for a particular type of thing that includes the model relay rules relating the component to peers within the recipe.

For example, a device driver makes a "cheese" peer and a co-occurrence engine recipe includes a "cheese holder", with model relay rules for connecting the "cheese". When some "cheese" becomes available, it is placed in the "cheese holder".

Probably the best API point we have currently for implementing this "dynamic injection" is "recordKnownComponent" here - There should be a Nexus API for this (perhaps a variant API of "fluid.construct") but we don't have it You can see this API being used in this capacity at the point where we construct "injected subcomponents" in fluid.initDependent here: