Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Repair Jira Macros

...

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. Post-

Jira Legacy
serverFluid Project Issue TrackerSystem JIRA
serverId2e29aa46e31a5874-ea43167a-32773fb1-bcd5ab47-0aa8908c274afcf749dd6c07
keyFLUID-6504
we reject such connection attempts. This issue is being tracked as
Jira Legacy
serverFluid Project Issue TrackerSystem JIRA
serverId2e29aa46e31a5874-ea43167a-32773fb1-bcd5ab47-0aa8908c274afcf749dd6c07
keyFLUID-6543
.

Add error messages to the model binding API (DONE)

...

3 feels nicer, and Kettle already has a scheme for sending "typed" messages. It should not complicate client implementations significantly, and would produce better feedback in interactive clients / client under development. Post-

Jira Legacy
serverFluid Project Issue TrackerSystem JIRA
serverId2e29aa46e31a5874-ea43167a-32773fb1-bcd5ab47-0aa8908c274afcf749dd6c07
keyFLUID-6504
the model binding WebSocket connection emits three types of messages, "initModel", "modelChanged", and "error".

...

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

Jira Legacy
serverFluid Project Issue TrackerSystem JIRA
serverId2e29aa46e31a5874-ea43167a-32773fb1-bcd5ab47-0aa8908c274afcf749dd6c07
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 has been initially implemented with

Jira Legacy
serverFluid Project Issue TrackerSystem JIRA
serverId2e29aa46e31a5874-ea43167a-32773fb1-bcd5ab47-0aa8908c274afcf749dd6c07
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.

...

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 has been implemented with

Jira Legacy
serverFluid Project Issue TrackerSystem JIRA
serverId2e29aa46e31a5874-ea43167a-32773fb1-bcd5ab47-0aa8908c274afcf749dd6c07
keyFLUID-6511
.