Comments (5)
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.
from fdc3.
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.
from fdc3.
@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).
from fdc3.
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.
from fdc3.
I believe we've settled this one (but will talk more offline), closing for now.
from fdc3.
Related Issues (20)
- Desktop Agent Bridging Discussion group 24th April 2024 HOT 6
- Standard WG Meeting - April 25th, 2024 HOT 10
- Context Clearing HOT 6
- Vulnerability in axios found by CVE scan
- General Meeting - May 7th, 2024 HOT 8
- Use Cases and Workflows Discussion Group - 2nd May 2024 HOT 8
- Don't bundle CSL license file into FDC3 NPM module
- FindIntentsByContextAgentRequest doesn't allow for supplying resultType
- FDC3 for Web Browsers Discussion group 16th May 2024 HOT 10
- Standard WG Meeting - May 23rd, 2024 HOT 7
- FDC3 Wealth Manager Persona
- FDC3 Business Analyst Persona
- FDC3 Interdealer Broker Persona
- FDC3 Client Services Persona
- FDC3 Operations Persona
- FDC3 Portfolio Manager Persona
- FDC3 Research Analyst Persona
- Use Cases and Workflows Discussion Group - 6th June 2024 HOT 10
- Conformance Tests Don't Cover PrivateChannel Listeners HOT 1
- FDC3 Identity & Threat Modelling -13 June 2024 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fdc3.