Multiple instances of the same application

[pgn-vole]

Question

Question Area

[ ] App Directory
[X ] API
[ ] Context Data
[ ] Intents
[ ] Use Cases
[ ] Other

Question

One of the basic use case I'm looking to enable is to allow user to open multiple instances of a single application, for instance multiples Chart or Tickets. Looking the current specification it seems that this use case is not covered, for example the raiseIntent API target parameter accepts an application name and not of application instance uuid (or something similar).
Have you put some thought already into that use case?

[lspiro-Tick42]

Managing application, application instances, discovery and also dynamically publishing new Intents (so applications can register them outside of the App Directory) are important parts of the Interop approach in Glue42. We have worked with DB in the Plexus project to produce an API that allows for this functionality. The API is defined here

I have a task to review this API and suggest what bits (if any) might be useful to bring into FDC3 API.

My opinion is that a proper Request/Response API is much better than trying to add return values to Intents, but that is a longer discussion.

There are implementations of this API for Plexus and for Glue42

[nkolba]

@pgn-vole
Handling app instances is a Desktop Agent implementation concern (not appD) as far as the standards go. Different platforms and technologies have different notions of what an application instance is and how to reference one. You can see an open source FDC3 implementation that handles this here. Since this implementation is a ChromeExtension - app instances are just separate tab instances (in Chrome) that happen to map to the same appD definition.

The resolution of multiple instances in the intent handler looks like this:

[lspiro-Tick42]

Nick, I don't think the interesting question is about Desktop Agent vs AppD, I think the question is the extent to which applications writing to FDC3 want to have 'control' over application instances.

For example if an application calls the FDC3 Open method, in our API's (and we will be proposing extensions to add this for FDC3) the application caller should receive a handle to an application instance, which they can use to close the instance. We also believe it should be possible for applications to use that instance handle to invoke intents on that instance.

We will further propose that the instance handle can be used to inquire what methods are supported by that application and invoke those methods using the Plexus Interop API, but that will be the subject of a separate issue

[pgn-vole]

@nkolba thanks for sharing this example implementation.
As I understand looking at the code, this implementation allows having multiple instances of a single application running at the same time, which is conforting since thatis what I was looking for. My understanding was wrong - I made this assumption looking at another desktop agent implementation which did prevent this behavior.

However I notice that ambiguity resolution that may occurs when calling raiseIntent is always delegated to the end user to solve . In your screenshot, since the viewChart is ambiguous the user has to manually choose which instance of the chart to target.

What we would like is something similar to what @lspiro-Tick42 is pointing out, where it is programatically possible to target one specific instance of an application when using raiseIntent because in many cases there is no need to ask the user to resolve ambiguity.
In fact looking at the implementation you linked it seems that the data is modeled that way, the "source" property of the raiseIntent response is an actual unique id of an instance of an application [1] which actually diverges from the specification example [2] where it seems it is expected of source to be the name of an application.

I do think thave having source as unique id make sense but in that case it means that the target property meaning should be updated and clarified.

1: https://github.com/finos/fdc3-desktop-agent/blob/ffaf54eb40c1e24c2a0af7e9228b8a89f18d69c1/src/bg-listeners.ts#L637
2: https://fdc3.finos.org/docs/1.1/api/ref/DesktopAgent#example-5

[nkolba]

@pgn-vole there is another API - https://fdc3.finos.org/docs/1.1/api/ref/DesktopAgent#findintentsbycontext - that is specifically for the use case of an application being able to control its own UX for intent resolution. In this case, the app can select the app instance it wants and launch that, using the target to specify the app instance (which corresponds to the source property of the intent resolution). It is not the case that source/target needs to be the app name. The spec is pretty clear that source can be used to reference the instance of the app:

There are a wide range of workflows where decoupled intents and/or context passing do not provide rich enough interactivity and applications are better off exposing proprietary APIs. In these cases, an App can use the source property on the resolution of an intent to connect directly to another App and from there, call remote APIs using the methods available in the Desktop Agent context for the App.

Happy to have this more explicit in subsequent iterations on the spec.

@lspiro-Tick42 - yes, please make the proposals.

-Nick

[pgn-vole]

Thanks for the clarification @nkolba - all make sense now.
I agree a bit of precision on the spec would be great. On that particular part I feel like they is quite some room for interpretation from the reader :)

Happy to have this issue closed.

[jonfreedman]

Is the result of findIntent & findIntentsByContext expected to return

1. All running application instances
2. All applications which are registered in 1..n AppDirectories
3. Both

& should that be explicit in the standard?

Also looking at AppMetadata how has your example screenshot offered up TradingView Chart - AAPL, TradingView Chart - MSFT & TradingView Chart? Is that because you have 3 charts running and the application names have been updated after you sent AAPL to one and MSFT to another?

[nkolba]

hi @jonfreedman

1. The spec leaves it up to implementation what the distinction is between apps and running app instances (as per comments above - this tends to be a fairly platform specific distinction).
2. again, this is left to the Desktop Agent implementation.

The reason for punting on specifics in the above was to keep the bar as low as possible for adoption by platforms, as well as to give platforms space to solve these (largely UX) problems on their own terms.

In the example, the Desktop Agent is identifying apps by URL registered in the App Directory, or by self-declaration of an intent handler at runtime. The application name is just the title of the tab instance for the app (HTML <title>). TradingView Chart - AAPL & TradingView Chart - MSFT are specific instances of the app. Trading View Chart is the "generic" app in the directory (i.e. new window). A nice feature here that I haven't gotten to yet would be to better indicate this distinction in the UI.

@pgn-vole If there are no further comments, I'll close this issue.

[jonfreedman]

While I get that each implementation probably does something sensible if this pattern of delegated API behaviour is by design then doesn't that imply that the fdc3 documentation is really only of use to desktop agent implementers? e.g. as an end user I can see what API methods I can call but I need to check elsewhere what they actually do, and if I contribute a suggestion to the API based on a use case there's no guarantee that I will ever actually be able to do what I wanted unless both the fdc3 maintainers and the desktop agent implementers agree with me?

[nkolba]

@jonfreedman there are some APIs that delegate certain choices to the desktop agent, others that don't. You are right that it is up to implementors ultimately to build the features application owners want. FDC3 maintainers and desktop agent implementors are highly intersectional groups, so raising use cases to the FDC3 group should generally get the job done. Part of the purpose of having an open source reference implementation of a desktop agent is to also enable the community to model behavior in FDC3 more directly.

[kriswest]

Closing in favour #450 which attempts to solve this issue (+ @pgn-vole commented that they were happy for the issue to be closed)