finos
Suggestion: fdc3.addContextListener() should accept an array of contextTypes to listen for
Enhancement Request
fdc3.addContextListener(type, handler) method should offer an option to pass an array of types the client is interested in.
Use Case:
A lot of our apps at LSEG are able to handle both fdc3.instrument and fdc3.instrumentList. As such, our apps add a handler for null to handle any of the two incoming context types. But given the example below, sometimes it is not possible to determine what is the latest between the two when an app is joining a channel.
LSEG is moving forward with the approach of offering to run our apps in our customers' platforms / Desktop Agents. Therefore we need to have a standardized way of ensuring we get the latest context between a subset of types when the app joins a channel to ensure consistency with the rest of the apps in the platform.
For example:
11:00 App A and App B both join channel green
11.01 App A broadcasts an instrument
11.02 App A broadcasts an instrumentList
11.03 App B broadcasts a contact
11.04 App C joins channel green
App C only supports instrument and instrumentList - but cotnact being the latest, how can App C determine that instrumentList was sent after instrument in this case?
Workflow Description
App C would add a context listener such as:
fdc3.addContextListener(['fdc3.instrument','fdc3.instrumentList'], (ctx) => { console.log(ctx); });
And, given the above example, when App C joins the channel, it would log instrumentList since it is the latest between 2 types in the channel.
This seems a worthwhile enhancement, as it fixes a flaw in the API design for a valid use case, and shouldn't be onerous for Desktop Agent vendors to implement. I think it the most ergonomic (for app developers) solution as it keeps code as simple as possible.
Accepting an array of context types would be a great improvement to the context listener; however, I believe we should preserve the existing behavior for the single string argument as well.
App B:
fdc3.addContextListener('fdc3.instrument', ctx => {})
Sequence: • App A joining channel green • App A broadcasting fdc3.instrument • App A broadcasting fdc3.contact • App B joining channel green
At this point, I assume App B may need to process the addContextListener for fdc3.instrument despite it not being the most recent context, but rather the only supported one.
@pvoznyuk and I had a chance to discuss this and agree that we should (and this proposal does) preserve the current behaviour for a single string argument. However, we also determined that the standard could be a lot clearer about whats expected of a Channel implementation regarding its stateful nature and that we should have a go at clarifying that further at the start of the Context Channels section and Channel API reference page, as at present we're only clear about the stateful nature of channels in the addContextListener and getCurrentContext references - which is far too late!
That clarification will need updating when resolving this issue and the metadata additions in #1290 (as more detail will need to be retained, such as the timestamps of messages).