Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Currently opening a model binding to a path where there is no component crashes the Nexus server. This is undesirably brittle. We may simply want to reject the connection, but it would be more faithful to the model relay paradigm of Infusion to allow such model bindings to lay dormant until a component does exist at that path, and then begin working in the normal manner. This issue is being tracked as FLUID-6504.

Allow binding to a component's complete model (DONE)

Currently the API demands that at non-empty path into a component's model is specified when establishing a binding. This means it is not possible to bind to the entirety of a component's model if it has more than one top-level key, e.g.

...

The Nexus should correctly interpret WebSockets opened at ws://{server}/bindModel/componentPath/ as addressing the entire model. This has been implemented with

Jira
serverFluid Project Issue Tracker
serverId2e29aa46-ea43-3277-bcd5-0aa8908c274a
keyFLUID-6516
.


Add a GET endpoint for /components/path.to.component (DONE)

Currently, WebSocket model bindings are the only way to get information about a component out of a Nexus "from the outside". The need for this functionality has come up in testing Nexus servers, but it may become necessary in use cases as well, and is nicely symmetrical with the GET endpoint for /defaults/. This issue is being tracked as has been initially implemented with

Jira
serverFluid Project Issue Tracker
serverId2e29aa46-ea43-3277-bcd5-0aa8908c274a
keyFLUID-6511
. Theoretically, this endpoint should provide an externalization of the addressed component, i.e. serialized data that could later be used to re-establish the component to its state at the time of the request, or could be modified outside the Nexus and later re-inserted to change the system's state. However, currently, we only expect to use this to perform tests of whether a component path is currently occupied or not.

Construct components with PUT rather than POST (DONE)

Currently, the API endpoint for constructing a component is to send an HTTP POST request to the /components/{desired component path} . The traditional distinction between PUT and POST is that the former puts a resource at a requested location, while the latter determines the final location of the resource and sends it back to the requester. Component construction follows the former case, and should therefore use PUT. This issue is being tracked as has been implemented with

Jira
serverFluid Project Issue Tracker
serverId2e29aa46-ea43-3277-bcd5-0aa8908c274a
keyFLUID-6511
.

Whole-Nexus avatar

One envisioned role for the Nexus is to provide a live "avatar" of its component tree to clients, which they may bind to local data or user interface components. Currently, the API could only support this by clients manually opening a WebSocket to the model of every Nexus component. The Visible Nexus built for the early Nexus demos provided a version of this functionality, which could possibly be folded into the Nexus proper.