You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The DesktopAgent's raiseIntent() function has an optional target parameter, allowing the developer to specify which application should resolve the intent:
target is currently specified via the application's name, which would often be retrieved via a call to findIntent() or findIntentsByContext(). These calls return an AppIntent Object, containing one or more AppMetadata objects, from which a name can be referenced.
As identified in another issue, there is currently a mismatch between the Desktop Agent and AppD specs where a name is assumed unique by the Desktop Agent, but potentially non-unique in the AppD (which can have multiple versions of the same app). Further, we might work with multiple AppD's, which could overlap on name values. By relying on the name property alone to identify an app we are open to situations where it cannot be resolved to a single component.
Workflow Description
By allowing target to be specified as an AppMetadata we can accomplish two things:
code using raiseIntent() can be simplified (no need to reference the name field inside the AppMetadata Object)
A desktop agent implementation could return additional fields in AppMetadata to help launch or target the application (or instance of an application) which it can then leverage when AppMetadata object is passed back to it.
Note the option to specify target as a string name is retained for backwards compatibility with the 1.1 spec.
Workflow Examples
letcontext={type: "fdc3.instrument",id: {ticker: "MSFT"}};fdc3.findIntentsByContext(context).then((appIntents)=>{//render something, user selects an intent and target app, e.g. let selectedAppIntentIdx = 1, selectedAppIdx = 3;letselectedAppIntent=appIntents[selectedAppIntent];letselectedApp=selectedAppIntent.apps[selectedAppIdx];fdc3.raiseIntent(selectedAppIntent.intent.name,context,selectedApp);});
Additional Information
We propose the following changes to the specification:
(switch first argument name to target for consistency with raiseIntent, support AppMetadata, retain the previous signature as overload for backwards compatibility with 1.1, consider deprecation of old signature)
The text was updated successfully, but these errors were encountered:
A desktop agent implementation could return additional fields in AppMetadata to help launch or target the application (or instance of an application) which it can then leverage when AppMetadata object is passed back to it.
I would avoid encouraging this because it means that the AppMetadata shape is going to be to the discretion of the desktop agent and therefore clients will have to have a understanding of the desktop agent they are dealing with to expect a predictable behavior of the open and raiseIntent APIs.
What I would suggest instead is to clarify how non-uniqueness of application instances can be handled with the existing standard.
In @nkolba's comment in a relevant issue on that matter it is mentioned that the raiseIntent input may be source rather than name, source which format is up to the desktop agent:
An example usage of such is the below:
constinstrument1={..}constinstrument2={..}// Spawn a chartconstresolution=awaitfdc3.raiseIntent('ViewChart',instrument1)console.log(resolution.source)// Could be anything really, example: "myChart/instance1"// Update existing chartfdc3.raiseIntent('ViewChart',instrument2,resolution.source)
There is however a hole that would prevent enabling your workflow which is that the "source" property is only surfaced within IntentResolution. So It seems to me that a good thing would be to surface it somwhere else. For instance findIntentsByContext may need to be extented to also list sources of each applications within its response.
Enhancement Request
Use Case:
The DesktopAgent's
raiseIntent()
function has an optional target parameter, allowing the developer to specify which application should resolve the intent:target
is currently specified via the application'sname
, which would often be retrieved via a call tofindIntent()
orfindIntentsByContext()
. These calls return anAppIntent
Object, containing one or moreAppMetadata
objects, from which aname
can be referenced.As identified in another issue, there is currently a mismatch between the Desktop Agent and AppD specs where a
name
is assumed unique by the Desktop Agent, but potentially non-unique in the AppD (which can have multiple versions of the same app). Further, we might work with multiple AppD's, which could overlap onname
values. By relying on thename
property alone to identify an app we are open to situations where it cannot be resolved to a single component.Workflow Description
By allowing
target
to be specified as anAppMetadata
we can accomplish two things:raiseIntent()
can be simplified (no need to reference the name field inside the AppMetadata Object)Note the option to specify target as a string
name
is retained for backwards compatibility with the 1.1 spec.Workflow Examples
Additional Information
We propose the following changes to the specification:
(Add AppMetadata as a valid type for target)
(switch first argument name to target for consistency with raiseIntent, support AppMetadata, retain the previous signature as overload for backwards compatibility with 1.1, consider deprecation of old signature)
The text was updated successfully, but these errors were encountered: