@finsemble/finsemble-core 6.1.4 → 6.1.5

package/dist/services/Interop/InteropService.md

@@ -1,148 +1,148 @@
-This is placeholder for documentation to come. These are notes from early discussions.
-
-/\*\*
-
-- Straw Man : How does SelectConnect work?
--
-- Every incoming InteropMessage converts to a redux action.
--
-- Non-broadcast actions (e.g. getSystemChannels, findIntent, joinChannel etc) are processed by reducers which update state and deliver (thunk) replies to the client
--
-- Broadcast actions run the SelectConnect algorithm. The algorithm results in an array of:
-- (1) destinations uuids
-- (2) the message (context and/or intent) for each destination, possibly transformed
--
--       The algorithm is a loop.
--        On start:
--     	  (1) The list of prospective destinations is initialized from the store (e.g. which uuids are listening for this message)
--
--        Each iteration:
--     		  Begins with the following data:
--               (a) the original message and meta data (e.g. intent type, context type, origination)
--               (b) a list of all rules that have not yet been triggered
--               (c) the current list of prospective destinations
--
--            Logic:
--               (i) Process each rule (in array order from config)
--                   Possibilities are:
--                     (A) `filter`: Eliminate or add destinations (e.g. from=* filter=#Linker)
--                     (B) `fork` : add destinations (e.g. to=#Chat fork=#Salesforce.Activity)
--                     (C) `selectConnect` : replace destinations (e.g. to=#Chat selectConnect=#Symphony)
--               (ii) Eliminate the rule (to avoid recursion and loops)
--               (iii) Exit loop when no rules are triggered during an iteration
--
--          When complete:
--     		  (a) Eliminate any destinations that don't have a valid handler (dead ends)
--            (b) Run auto-translation algorithm
--            (c) Update the store to reflect new client state
--            (d) Deliver messages using asynchronous thunks
--
-- TBD:
-- Do rules need to make a destinction between "from":"to" and "origination":"destination"?
--       e.g. to prevent skirting filters by redirection
-- How to prevent broadcast storms?
--       Not just internal to the resolver, but if receipt of a message by a destination triggers a broadcast, and vice versa
--         Stitchview ran into this pretty quickly and implemented a timeout, to silently drop any messages of the same contextType if received within x milliseconds
-- Translation
--       What do rules look like? How do apps or system channels register translations?
-  \*/
-
-/\*\*
-
-- System channels:
--
-- By convention, system channels begin with #. Some system channels like #Linker are built in.
-- Other system channels, such as #Symphony, would be registered via config. Registering via config prevents
-- other apps from hijacking those channel names.
--
-- System channels are not "peer" based. When a message is sent to a system channel, only the system channel
-- handler receives that message (not any other listeners).
--
-- System channels may support a syntax, such as #Symphony@tradebot or #Excel@G6F4.
--
-- TBD: how to communicate that syntax to the system app with a given FDC3 message
-- TBD: how the system channel can communicate back to a specific app
--         ? implicitly create a channel for every uuid
--         ? how would the system channel be informed
--         ? how would the system channel know when to remove uuid references
--         ? is it even necessary for system channels to communicate back? Maybe data-driven intents is good enough
--
-- Private channels:
--
-- Apps can specify private channels via config. A private channel essentially establishes a #Fence (see below) around
-- a well known channel. For instance, a suite of related apps might need a way to communicate amongst themselves
-- without eavesdropped or imposters.
--         ? Could this be accomplished just as easily with a #Fence rule?
--
-- Rules Examples:
--
-- When an app (e.g. telephony) receives a call, launch an app called "Screenpop" (context is passed automatically)
-- intent=call selectConnect=#Launch@Screenpop
--
-- When any intent is sent to the #Chat channel, also send it to a Salesforce driver that creates Activity records, and if possible transform the data into a SalesforceRecord
-- intent=\* to=#Chat fork=#Salesforce.Activity #transform=#Salesforce.Record
--
-- Possible plugins/system channels:
--
-- #Linker - Adds or removes destinations based on linkage (probably a filter, maybe a type of #Fence)
-- `from=* filter=#Linker`
--
-- #DragNDrop - Removes destinations but stores the data so that it can be emitted when the user drags between windows
-- `from=Chart contextType=Symbol fork=#DragNDrop`
--
-- #Launch@Chart - Launches apps, passing the contextType/intent to the launched app
-- `intent=Screenpop selectConnect=#Launch@Chart@SalesforceActivity`
--
-- #Logger@info - Sends the info to a log (probably a fork)
-- `from=ProjectEditor intent=Error fork=#Logger@error`
--
-- #Workspace - Saves info in a workspace, and then when the workspace is relaunched, emits that info back to the app
-- `contextType=symbol fork=#Workspace`
--
-- #Fence - Prevents messages from going to apps that aren't in the fence (like a composite but maybe other logical groupings)
-- `from=Chart contextType=symbol selectConnect=#Fence` - Keeps a symbol broadcast from escaping the fence (but still lets symbol into the fence from outside)
-- `to=Chart contextType=date filter=#Fence` - Prevents a date broadcast from entering the fence
--
-- #Trash - /dev/null for messages
-- `from=Chart to=Grid selectConnect=#Trash`
--
-- #ODAC - Open Data Access Control. Filter messages throuh an access control list (ACL)
-- `from=CRD filter=#ODAC` - Prevents delivery to any destination not in the ACL
--
-- #Notification - Could be used for sending notifications, or to set rules for data that is delivered by a notification.
-- Notifications should probably be genericized to publish intent/context when the user clicks on them. So in a sense
-- a notification is like #DragNDrop, where broadcast is deferred until the user clicks on something
-- `intent=Trade contextType=FixedIncome selectConnect=#Notification#Bob`
-- `intent=Trade from=#Notification selectConnect=#Launch@FixedIncomeApp`
--
-- #Search - Most useful with a data-driven intent, could take the place of our search providers
-- Also, search results should be intents/contextTypes so that clicking on a result either triggers an action or a context switch
-- `from=#Search contextType=Link #Launch@Browser`
--
-- #Chat@slackbot - Routes messages to and from a chat network. We might build plugins that work with symphony, slack and teams
-- `intent=Trade selectConnect=#Chat#tradechannel`
--
-- #ChatCreator - Our own pop-up app that allows a user to create a chat message to be sent to #Chat (like our sales demo)
-- Maybe this just listens for a specific intent...
-- `intent=Trade selectConnect=#Intent@CreateChat`
--
-- #CRM@activity - Send data to the CRM system. We could build plugins that work with Salesforce or other systems
-- `to=#Chat contextType=Trade fork=#CRM@activity` - Log an activity record every time we send a trade via chat
--
-- #Symphony, #Salesforce - Maybe instead of generic #Chat, #CRM we would have specific channels for specific 3rd parties
--
-- #Bloomberg@SRCH - Runs a bloomberg command
-- `contextType=Symbol to=#Search fork=#Bloomberg@SRCH` - Sends all searches also to Bloomberg
--
-- #Excel@MySheet!A1\*10 - Sends data to a specific cell in Excel
-- `contextType=Symbol fork=#Excel@MySheet!A1*10`
--
-- #Intent@Share - Convert a context broadcast into an intent
-- `from=Chart contextType=Symbol selectConnect=#Intent:Quote` - Whenever the chart changes symbols, ensure that an app is available that shows a Quote for that same symbol
-- `intent=Trade selectConnect=#Intent@Chat` - If there's a chat tool that only accepts intents we can use conversion. Might require an automatic translation (e.g. stringify into a Chat envelope) \*/
-
-Obscure errors as the result of misuse of Immer
-
-Always call `current` if you need to pass a piece of store state outside of your reducer.
-
-TypeError: Cannot perform 'get' on a proxy that has been revoked TypeError: Cannot perform 'isExtensible' on a proxy that has been revoked TypeError: Cannot read property 'Symbol(nodejs.util.inspect.custom)' of null
+This is placeholder for documentation to come. These are notes from early discussions.
+
+/\*\*
+
+- Straw Man : How does SelectConnect work?
+-
+- Every incoming InteropMessage converts to a redux action.
+-
+- Non-broadcast actions (e.g. getSystemChannels, findIntent, joinChannel etc) are processed by reducers which update state and deliver (thunk) replies to the client
+-
+- Broadcast actions run the SelectConnect algorithm. The algorithm results in an array of:
+- (1) destinations uuids
+- (2) the message (context and/or intent) for each destination, possibly transformed
+-
+-       The algorithm is a loop.
+-        On start:
+-     	  (1) The list of prospective destinations is initialized from the store (e.g. which uuids are listening for this message)
+-
+-        Each iteration:
+-     		  Begins with the following data:
+-               (a) the original message and meta data (e.g. intent type, context type, origination)
+-               (b) a list of all rules that have not yet been triggered
+-               (c) the current list of prospective destinations
+-
+-            Logic:
+-               (i) Process each rule (in array order from config)
+-                   Possibilities are:
+-                     (A) `filter`: Eliminate or add destinations (e.g. from=* filter=#Linker)
+-                     (B) `fork` : add destinations (e.g. to=#Chat fork=#Salesforce.Activity)
+-                     (C) `selectConnect` : replace destinations (e.g. to=#Chat selectConnect=#Symphony)
+-               (ii) Eliminate the rule (to avoid recursion and loops)
+-               (iii) Exit loop when no rules are triggered during an iteration
+-
+-          When complete:
+-     		  (a) Eliminate any destinations that don't have a valid handler (dead ends)
+-            (b) Run auto-translation algorithm
+-            (c) Update the store to reflect new client state
+-            (d) Deliver messages using asynchronous thunks
+-
+- TBD:
+- Do rules need to make a destinction between "from":"to" and "origination":"destination"?
+-       e.g. to prevent skirting filters by redirection
+- How to prevent broadcast storms?
+-       Not just internal to the resolver, but if receipt of a message by a destination triggers a broadcast, and vice versa
+-         Stitchview ran into this pretty quickly and implemented a timeout, to silently drop any messages of the same contextType if received within x milliseconds
+- Translation
+-       What do rules look like? How do apps or system channels register translations?
+  \*/
+
+/\*\*
+
+- System channels:
+-
+- By convention, system channels begin with #. Some system channels like #Linker are built in.
+- Other system channels, such as #Symphony, would be registered via config. Registering via config prevents
+- other apps from hijacking those channel names.
+-
+- System channels are not "peer" based. When a message is sent to a system channel, only the system channel
+- handler receives that message (not any other listeners).
+-
+- System channels may support a syntax, such as #Symphony@tradebot or #Excel@G6F4.
+-
+- TBD: how to communicate that syntax to the system app with a given FDC3 message
+- TBD: how the system channel can communicate back to a specific app
+-         ? implicitly create a channel for every uuid
+-         ? how would the system channel be informed
+-         ? how would the system channel know when to remove uuid references
+-         ? is it even necessary for system channels to communicate back? Maybe data-driven intents is good enough
+-
+- Private channels:
+-
+- Apps can specify private channels via config. A private channel essentially establishes a #Fence (see below) around
+- a well known channel. For instance, a suite of related apps might need a way to communicate amongst themselves
+- without eavesdropped or imposters.
+-         ? Could this be accomplished just as easily with a #Fence rule?
+-
+- Rules Examples:
+-
+- When an app (e.g. telephony) receives a call, launch an app called "Screenpop" (context is passed automatically)
+- intent=call selectConnect=#Launch@Screenpop
+-
+- When any intent is sent to the #Chat channel, also send it to a Salesforce driver that creates Activity records, and if possible transform the data into a SalesforceRecord
+- intent=\* to=#Chat fork=#Salesforce.Activity #transform=#Salesforce.Record
+-
+- Possible plugins/system channels:
+-
+- #Linker - Adds or removes destinations based on linkage (probably a filter, maybe a type of #Fence)
+- `from=* filter=#Linker`
+-
+- #DragNDrop - Removes destinations but stores the data so that it can be emitted when the user drags between windows
+- `from=Chart contextType=Symbol fork=#DragNDrop`
+-
+- #Launch@Chart - Launches apps, passing the contextType/intent to the launched app
+- `intent=Screenpop selectConnect=#Launch@Chart@SalesforceActivity`
+-
+- #Logger@info - Sends the info to a log (probably a fork)
+- `from=ProjectEditor intent=Error fork=#Logger@error`
+-
+- #Workspace - Saves info in a workspace, and then when the workspace is relaunched, emits that info back to the app
+- `contextType=symbol fork=#Workspace`
+-
+- #Fence - Prevents messages from going to apps that aren't in the fence (like a composite but maybe other logical groupings)
+- `from=Chart contextType=symbol selectConnect=#Fence` - Keeps a symbol broadcast from escaping the fence (but still lets symbol into the fence from outside)
+- `to=Chart contextType=date filter=#Fence` - Prevents a date broadcast from entering the fence
+-
+- #Trash - /dev/null for messages
+- `from=Chart to=Grid selectConnect=#Trash`
+-
+- #ODAC - Open Data Access Control. Filter messages throuh an access control list (ACL)
+- `from=CRD filter=#ODAC` - Prevents delivery to any destination not in the ACL
+-
+- #Notification - Could be used for sending notifications, or to set rules for data that is delivered by a notification.
+- Notifications should probably be genericized to publish intent/context when the user clicks on them. So in a sense
+- a notification is like #DragNDrop, where broadcast is deferred until the user clicks on something
+- `intent=Trade contextType=FixedIncome selectConnect=#Notification#Bob`
+- `intent=Trade from=#Notification selectConnect=#Launch@FixedIncomeApp`
+-
+- #Search - Most useful with a data-driven intent, could take the place of our search providers
+- Also, search results should be intents/contextTypes so that clicking on a result either triggers an action or a context switch
+- `from=#Search contextType=Link #Launch@Browser`
+-
+- #Chat@slackbot - Routes messages to and from a chat network. We might build plugins that work with symphony, slack and teams
+- `intent=Trade selectConnect=#Chat#tradechannel`
+-
+- #ChatCreator - Our own pop-up app that allows a user to create a chat message to be sent to #Chat (like our sales demo)
+- Maybe this just listens for a specific intent...
+- `intent=Trade selectConnect=#Intent@CreateChat`
+-
+- #CRM@activity - Send data to the CRM system. We could build plugins that work with Salesforce or other systems
+- `to=#Chat contextType=Trade fork=#CRM@activity` - Log an activity record every time we send a trade via chat
+-
+- #Symphony, #Salesforce - Maybe instead of generic #Chat, #CRM we would have specific channels for specific 3rd parties
+-
+- #Bloomberg@SRCH - Runs a bloomberg command
+- `contextType=Symbol to=#Search fork=#Bloomberg@SRCH` - Sends all searches also to Bloomberg
+-
+- #Excel@MySheet!A1\*10 - Sends data to a specific cell in Excel
+- `contextType=Symbol fork=#Excel@MySheet!A1*10`
+-
+- #Intent@Share - Convert a context broadcast into an intent
+- `from=Chart contextType=Symbol selectConnect=#Intent:Quote` - Whenever the chart changes symbols, ensure that an app is available that shows a Quote for that same symbol
+- `intent=Trade selectConnect=#Intent@Chat` - If there's a chat tool that only accepts intents we can use conversion. Might require an automatic translation (e.g. stringify into a Chat envelope) \*/
+
+Obscure errors as the result of misuse of Immer
+
+Always call `current` if you need to pass a piece of store state outside of your reducer.
+
+TypeError: Cannot perform 'get' on a proxy that has been revoked TypeError: Cannot perform 'isExtensible' on a proxy that has been revoked TypeError: Cannot read property 'Symbol(nodejs.util.inspect.custom)' of null

package/dist/services/Interop/InteropServiceUI.css

@@ -1,12 +1,12 @@
-html,
-body,
-#InteropServiceUI-tsx {
-	height: 100%;
-	background-color: white;
-	color: black;
-}
-
-.devTools {
-	width: 100%;
-	height: 99%;
-}
+html,
+body,
+#InteropServiceUI-tsx {
+	height: 100%;
+	background-color: white;
+	color: black;
+}
+
+.devTools {
+	width: 100%;
+	height: 99%;
+}