Question: Are we missing an addIntentForContextListener?

[Roaders]

Question Area

• [ ] App Directory
• [x] API
• [ ] Context Data
• [ ] Intents
• [ ] Use Cases
• [ ] Other

Question

Correct me if I am wrong but it's currently not possible for an app to add an intent listener that will fire when raiseIntentForContext is called? The only way for raiseIntentForContext to be actioned is with app metadata retrieved through the app directory.

We wouldn't actually need an addIntentForContextListener function I donlt think. We could just add an optional argument to the addIntentListener function:

addIntentListener(intent: string, handler: IntentHandler, context?: string[]): Promise<Listener>;

This seems like a gap to me. I don't really have a use case for this other than the fact I am trying to test raiseIntentForContext and we don't quite have our app directory implemented yet (it's nearly there).

[kriswest]

This is indeed a well-known gap. At present, appD metadata (interop.intents.listensFor) is the only way to set context types for 'dynamically registered intent listeners'. The relevant section of the standard overview is:

Applications need to let the system know the intents they can support. Typically, this SHOULD be done via registration with an App Directory by providing interop.intents.listensFor metadata. However, Desktop Agent implementations MAY support dynamic registration of an IntentHandler by an app at runtime (for example, when they add an IntentListener via the API) to allow for ad-hoc registration which may be helpful at development time. Although dynamic registration is not part of this specification, a Desktop Agent agent MAY choose to support any number of registration paths.

https://fdc3.finos.org/docs/api/spec#register-an-intent-handler

This ignores the fact that you can't set the context types in addIntentListener. In my experience, dynamic registration is mostly used at development time and with tools like the FDC3 workbench, which is much easier to use if it can dynamically register an intent handler. To make that work with the current standard the best approach I know is to assume that a dynamically registered listener matches all context types, i.e. ignore the context filter if you didn't find an appD record or it did not include an interop.intents.listensFor element, thus enabling dynamic registration for development use cases.

If you could set the context type filter (as you propose) we'd also have to determine and document what the behaviour should be if the filter set in the appD does not match that set in the API call.

[Roaders]

This has obviously been thought about before and as you say, the main requirement for this is when working with testing tools rather than a real prod use case. Thanks for the reply. I am happy to close the issue.