Metadata
- Source
- FLUID-6494
- Type
- New Feature
- Priority
- Major
- Status
- Open
- Resolution
- N/A
- Assignee
- Philip Tchernavskij
- Reporter
- Philip Tchernavskij
- Created
2020-04-17T14:03:38.127-0400 - Updated
2020-04-17T14:03:38.127-0400 - Versions
- N/A
- Fixed Versions
- N/A
- Component
-
- Nexus
Description
The nexus-gsheets library currently provides basic support for externalizing Google sheets documents in Infusion applications. However, we still have not worked out the details of how the provided grades will be deployed.
The attached image is a sketch of an imagined use case, where a Nexus instance running on a server or locally takes care of managing and connecting various remote resources such as spreadsheets and sensors, and a 'regular' Infusion instance running in a browser provides a UI for interacting with the Nexus components.
In this sketch, some of the components in the Nexus are mirrored in the browser, so that they can be connected to the UI through Infusion's declarative constructs, i.e. model relays, listeners etc. This mirroring facility is currently missing from the Nexus, though a version of it was implemented for the [Visible Nexus demo|https://github.com/amb26/fluid-authoring/blob/FLUID-4884/src/server/js/VisibleNexus.js.] We should evaluate whether to extend the Nexus API with this feature. Apropos, this is reminiscent of the Shared Substance middleware, which allows parts of a distributed component tree to be mounted or replicated on multiple machines.
In addition to figuring out the network topology of our spreadsheet integration tools, this issue also invites work on the (end-user and developer) workflow for setting up and configuring an integration tool. For example:
- Each user will have to give the API client access to their personal spreadsheets to create a token file authorizing the client. How does the Nexus communicate with the browser to represent this exchange? Can we store a token on the browser, so users don't transmit their consent to our server?
- Currently, there is no declarative/static mechanism to package a Nexus with a set of custom grades. Should we extend the Nexus with a system a la Kettle's capacity for static configuration files?