onAddIntentListener JSON Schema like PC.onAddContextListener

[robmoffat]

Enhancement Request

I am guessing that at the moment, the design is that when an intent is raised, it is sent to every other desktop agent. However, it might be a good idea to have a message for the desktop agent to receive a message for when the app adds or removes an intent listener?

[kriswest]

No, not quite right. Raised intents should always be targetted at a specific DA and appId, with an optional instanceId. What is expected is that the DA on which the intent was raised will sendfindIntent messages to all other agents, receive back the consolidated options from the bridge, combine them with its own options, present an intent resolver to the user (if one is needed) and then finally send the raiseIntent message with full targeting (desktopAgent, appId, instanceId if appropriate).

This means that the user experience for intent resolution is provided in the DA where the raiseIntent is performed, it'll just have extra options to show from across the bridge.

Hence, there is no need in bridging for an onAddIntentListener exchange. It's down to a DA to know what app instances there are with intent listeners and to respond to findIntent messages with details of them (+apps it can start), then to deliver raiseIntent messages received from the bridge targetted at those listeners.

This is detailed in the first two paragraphs here: https://fdc3.finos.org/docs/next/agent-bridging/ref/raiseIntent

If its not clear, I'm happy to make any content edits you suggest.

[robmoffat]

Hi @kriswest,

That is perfectly clear. What isn't quite so clear I guess is my thinking on this in the first place, so this is really helpful. Here's a scenario:

• Desktop Agent (DA) has two apps running, App A and App B.
• App B has an intent listener registered for "createBook" intent.
• App C is not running, but does declare in it's appD record that it responds to "createBook"
• App A then does findIntent.
• If DA wants to return a list containing [B, C] then it needs to know that B has registered the intent listener.
• However, there is no message to do this.

I can see that this is kind of "out-of-scope" for bridging, but it would nevertheless be very useful from protocol point of view, otherwise, in order to respond correctly, the DA would have to send something like a "findIntent" message to B to see if it responds to the intent before collating all the results to send back to A.

[kriswest]

@robmoffat are you conflating/thinking about briding and FDC3 for the web in parallel? That would make this more complex as I think those cases differ a fair bit.

In the FDC3 for the Web (or indeed any normal single DA case), then the Desktop does know that B has added the intent listener, because it handled the call to add it. Assuming, that B supports multiple instance AND that its appD entry states that it supports the intent/context pair then the DA should return (for findIntent OR and intent resolver) [instance of B, start new B, start new C] and has all the info to do so.

In the bridging case, then theres a couple of possible cases to explore:

• B is on the same DA,
• B is on the other DA.

The first case is the same as the regular FDC3 case - the DA handled the addIntentListener call and so knows about it. It collects options from the other DA via findIntent, combines with its own options (that include the instance of B) and show the result to the user.

The second case (B is ont he remote DA) is handled by sending out findIntent to the remote DA (doesn't make sense to send to an app), then combining the options that it gets back (which include the remote instance, which its DA knew about) with its own and showing the user. If the user picks the remote option, then a raiseIntent with that target is sent to the remote DA.

This is far far simpler than attempting to maintain details of every instance being managed by every DA all the time, which is what you'd have to do if the was just going to know the answer (we'd have to share details on connection to bridge and on every launch/close, every add/unsubscribe of a listener, as opposed to just on a raised intent).

However, I think you are thinking about the FDC3 for Web case. In that situation, you need to support a message from the app to the DA for addIntentListener (and every other API call in the API). The DA then needs to maintain state for all apps and listeners - which is the same as for any DA implementation. You would NOT need to send a findIntent call to the app as that doesn't make sense when you already know it added a listener.

What I think you are running into is that bridging doesn't have an addIntentListener message as it doesn't need one and you are reusing those messages in your FDC3 for the Web POC. FDC3 for the web needs a message for every API call (and response) - working up a complete set of those is necessary to get this done. I can get an envelope and examples for those started this week and work up a todo list - I also need to review Terry's attempt at the docs and TypeScript which may have addressed this already (so I should probably start there).

[robmoffat]

Hi @kriswest ,

Yes, sorry. All of my questions about bridging are related to FDC3 for the web! Your last paragraph was the key one for me, thanks. I'll let you know of any others as I come across them.

[kriswest]

I believe we've settled this one (but will talk more offline), closing for now.