Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This document collects changes we would like to make to the Nexus API as we build more complex distributed systems with it.


Reverse the options-flattening revolution

The Nexus was originally designed at a moment when the expectation was that Infusion would soon move away from the convention of specifying components to-be-constructed with a record a la

{
    type: "fluid.component",
    options: {
        myOption: "someValue"
    }
}


and instead write the contents of the "options" record at the top level (FLUID-5750). This change of convention has not occurred in the rest of the Infusion ecosystem, so the Nexus now operates a different convention than everyone else, creating confusion for programmers who are likely to use the Nexus alongside Kettle on the server and Infusion on the client. For the time being, the Nexus ought to either accept both conventions, or move fully to the more general one.

Allow binding to non-existent components

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.

Construct components with PUT rather than POST

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.

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.

  • No labels