Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow target to be defined by AppMetadata #270

Closed
sean-ciq opened this issue Oct 19, 2020 · 2 comments
Closed

Allow target to be defined by AppMetadata #270

sean-ciq opened this issue Oct 19, 2020 · 2 comments
Labels
enhancement New feature or request
Milestone

Comments

@sean-ciq
Copy link
Contributor

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:

raiseIntent(intent: string, context: Context, target?: string): Promise<IntentResolution>;

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

let context = {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;
    let selectedAppIntent = appIntents[selectedAppIntent];
    let selectedApp = selectedAppIntent.apps[selectedAppIdx];
   fdc3.raiseIntent( selectedAppIntent.intent.name, context, selectedApp  );
});

Additional Information

We propose the following changes to the specification:

raiseIntent(intent: string, context: Context, target?: AppMetadata | string): Promise<IntentResolution>;

(Add AppMetadata as a valid type for target)

open(name: string, context?: Context): Promise<void>;
open(target: AppMetadata | string, context?: Context): Promise<void>;

(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)

@sean-ciq sean-ciq added the enhancement New feature or request label Oct 19, 2020
@sean-ciq sean-ciq reopened this Oct 19, 2020
@sean-ciq
Copy link
Contributor Author

For inclusion in the 1.2 spec. Credit to @kriswest for actually writing this.

@pgn-vole
Copy link

pgn-vole commented Oct 26, 2020

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:

const instrument1 = {..}
const instrument2 = {..}

// Spawn a chart
const resolution = await fdc3.raiseIntent('ViewChart', instrument1)

console.log(resolution.source) // Could be anything really, example: "myChart/instance1"

// Update existing chart
fdc3.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.

@rikoe rikoe added this to the 1.2 milestone Jan 26, 2021
@rikoe rikoe closed this as completed Jan 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants