Enhancement Request

Extend the AppD's Application definition to include details of how an application uses Interop, including:

• what context types are supported by the application.
• how those context types are used (listen or broadcast on user (system) channels, app channels or passed with an intent).
• what app channel sit broadcasts on or listens to.
• what intents and contexts it can raise.

Use Case:

When assembling a desktop, Users (or desktop implementors) may wish to search an App directory for applications that 'work with' a selected application. This is currently not possible as AppD application records can only provide detail on intent/context combination that can be handled, and does not provide information on intents/context raised, channels or contexts broadcast/listened to on them.

Additionally, app developers or Desktop Agent vendors may wish to be able to build UIs that can fdc3.open applications supporting a particular context. This information is known to the desktop agent at runtime after the application has been started, but is not known to either the Desktop Agent or application developer in advance except by direct interaction with the developer/publisher of each application.

N.B. additional changes may be needed for the FDC3 API to support the latter use case. However, a first step to doing so is to decide if and how the necessary information is provided to the Desktop Agent.

Workflow Description

A desktop agent or desktop developer may wish to implement functionality that leverages information on what context types are broadcast and listened to by applications in the desktop. E.g. The user browses an Application catalog UI (backed by an AppD instance) to select applications for their desktop and adds one (e.g. a view of the current orderbook developed in-house) to their launcher app. They then wish to find other applications that will work with it, both in an application catalog and via an 'open in ...' function (fdc3.open) or 'perform action' (fdc3.raiseIntent, fdc3.raiseIntentForContext, fdc3.findIntent, fdc3.findIntentForContext) function within the application itself.

Workflow Examples

A user (or desktop administrator that manages a desktop for users) is browsing an app catalog to select applications for use on their desktop:

• The app selected supports context sharing via fdc3.broadcast, the user wishes to see a list of other apps in the application catalog that listen for that context via channel linking (fdc3.addContextListener)
• The app selected supports context listening via fdc3.addContextListener, the user wishes to see a list of other apps in the application catalog that broadcast that context via channel linking (fdc3.broadcast)
• The app selected supports intent handling via fdc3.addIntentListener, the user wishes to see a list of other apps that can raise the intent (with the necessary context)
• The app selected supports raising intents with a particular context type, the user wishes to see a list of apps that can handle the intents with the specified context.
• The app wishes to provide an option in its UI (or one provided by the desktop agent) to 'open in ...' another application, similar to a resolver that you can build for raiseIntent.

Additional Information (edited 22/04/22)

The Desktop Agent API supports a number of methods of passing context to applications:

• raiseIntent (Intent + context)
• raiseIntentForContext (context + any intent)
• open (with context)
• broadcast (on user or app channels)

However, the AppD spec currently only supports declaring the intents listened for and associated context types and does not provide information on what contexts are supported for fdc3.open, fdc3.broadcast and fdc3.addContextListener, nor what intents may be raised.

To help provide information to a resolver for raiseIntent (where a filtered set of applications that support the intent and context type must be determined), the AppD spec defines an intents element to be used to declare the supported intents and associated contexts. This information is required in order to implement intent resolution within the Desktop Agent. In contrast, the additions proposed by this issue are NOT required for resolving FDC3 API calls and do not imply any form of contract with the Desktop Agent, but are instead useful in implementing an app catalog to render app directory content. As such, providing this information in an AppD record should be considered optional, but recommended (SHOULD).

Proposed additions to the App Directory record (edited 22/04/22):

{
  "appId": "string",
  "name": "string",
  ...
  "intents": [                         // existing intents element
    {
      "name": "string",
      "displayName": "string",
      "contexts": [ "string" ],
      "customConfig": {}
    }
  ],
  "interopUse": {                      // new interopUse element
    "raisesIntents": {
      "string" : [ "string" ]          //intent: [ contextType ]
    }
    "userChannelContexts": {
      "broadcast": [ "string" ],       // [ contextType ]
      "listen": [ "string" ]           // [ contextType ]
    },
    "appChannels": [
      {
        "name": "string",              // channel name (as used with `fdc3.getOrCreateChannel`)
        "description": "string",       // description of channels purpose/usage
        "broadcast": [ "string" ],     // [ contextType ]
        "listen": [ "string" ]         // [ contextType ]
      }
    ]  
  }
}

Note:

• An "open" element is NOT necessary as open is:

  ... functionally equivalent to opening the target app with no context and broadcasting the context directly to it
  and should be handled via the userChannels.listen element.

• With such a config in place, it would be possible to extend the Desktop Agent API to provide a resolver function to the API:

  enum Operation {
    BROADCAST = "broadcast",
    LISTEN = "listen"
    RAISEINTENT = "raiseIntent
  }
  findAppsByContext(context: Context, operation?: Operation): Promise<Array<AppMetadata>>;

  however, this could/should be raised as a separate issue if the above is accepted.