Alternative App definition and Intent description proposal


Swagger for proposed Application and Intent schema

I have uploaded a Swagger/OpenApi YAML file that holds the Glue42 proposal for an Application definition and for an Intent definition.

Discussion of the Intent definition may be out of scope for the Working Group but I have included it because it is referenced in the schema. The spec also holds some null services so I can test and view the spec in the Swagger Editor UI.

I am not sure how to prepare the data for viewing in Confluence. I am going to include the definition of the Application here for people who are not going to download and read the full spec,

There are two key points to highlight :

  • The applications now have a type which can be Desktop Exe, Browser and Container to allow an App Directory to specify multiple app types. This is particularly useful for in-house App Directories used in an Enterprise setting.
    We also allow custom types to support specific local features like storing 'Layouts' in an App Directory.
  • A Container application can support multiple containers, this is a way to move all the container specific configuration outside the spec. This will allow 3rd parties to publish application definitions which can run on a variety of desktop containers/


    Application:
      description: >
        Defines an application retrieved from an FDC3 App Directory, which can then be launched. 
        Launching typically means running for a user on a desktop, but the concepts around laucnhing including 
        who or what might do it, and how the launch action is initiated are discussed elsewhere in the FDC3 App Directory spec.
      required:
        - name
        - appType
        - appDetails
      properties:
        name:
          type: string
          description: |
            The name of the application. 
            The name should be unique within an FDC3 App Directory instance. The exception to the uniqueness constraint is that an App Directory can hold definitions for 
            multiple versions of the same app.
            The same appName could occur in other directories. We are not currently specifying app name conventions in the document. 
             
        appType:
          type: string
          description: |
            The type of the application. There should be predefined values, the different application types would also have different data fields. 
            Custom values will also be allowed to enable the use of in-house or 3rd party specific values such as layouts to be specified. 
            Launchers are expected to ignore applications of a custom type that they do not support.
            The standard values proposed are  
            - DesktopExe. Some executable on the desktop. The detailed definitions could allow for Windows and Mac. This would mainly be used for specifying in-house applications 
            developed using .Net.
            - Container. A Web Application detined to run in a container. The Container application type coud include meta data for the various container types that an 
            application vendor may support. 
            - Custom.{Vendor}.{CustomAppType}. Additional private application types can be specified. It reuqires co-ordination between the  launcher and the App Directory instances to
            allow these values to be used. An example would be to allow Desktop Layouts to be specified in an in-house App Directory Instance

        version: 
          type: string
          description: Version of the application. This allows multiple app versions to be defined using the same app name. This can be a triplet but can also include things like 1.2.5 (BETA) 

        title:
          type: string
          description: Optional title for the application, if missing use appName, typically used in a launcher UI.

        tooltip:
          type: string
          description: Optional tooltip description e.g. for a launcher

        description:
          type: string
          description: Description of the application. This will typically be a 1-2 paragraph style blurb about the application. Allow mark up langua

        images:
          type: array
          description: Array of images to show the user when they are looking at app descritpion. Each image can have an optional description/tooltip
          items:
            $ref: '#/components/schemas/AppImage'

        contactEmail:
          type: string
          description: Optional e-mail to receive queries about the application

        supportEmail:
          type: string
          description: Optional e-mail to receive support requests for the application

        publisher:
          type: string
          description:  The name of the company that owns the application. The publisher has control over their namespace/app/signature(see diagram). 

        icons:
          type: array
          description: Holds Icons used for the application, a Launcher may be able to use multiple Icon sizes or there may be a 'button' Icon
          items:
            $ref: '#/components/schemas/Icon'

        customConfig:
          type: array
          description: An optional set of name value pairs that can be used to deliver custom data from an App Directroy to a launcher.
          items:
            $ref: '#/components/schemas/NameValuePair'

        intents:
          type: array
          description: |
            The list of intents implemented by the Application.

            NB The usage and meaning of Intents is still under discussion in the Intent WG (as of 27-Jun-18). See the comment on '#/components/schemas/Intent' for details.
            I think the essence of the 'debate' is around how closely the terminology should match that used in Android. 
            I believe that in Android this intents field (within the Application definition) would be called actions and would effectively hold an Intent name and a Context,
            where a context is an object type like Contact or Symbol.Equity that serves as a restriction on where the Intent/Action is valid. 
            However the current Intent definition can hold a Context so the split between action and intent is not strictly necessary.
          items:
            $ref: '#/components/schemas/Intent'

        appDetails:
          description: Depending on appType, expect to see one of the following for the app details
          oneOf:
            - $ref: '#/components/schemas/AppExe'
            - $ref: '#/components/schemas/AppBrowser'
            - $ref: '#/components/schemas/AppContainer'
            - $ref: '#/components/schemas/AppCustom'
    
    AppExe:
      required:
          - exePath
      description: Holds data for an appType=Exe
      properties:
        exePath:
          type: string
          description: URI to the application, expect to use FILE:\\ style URI
        allowMultiple:
          type: boolean
          description: SHould a launcher create a new instance or try and focus an existing instance

    AppBrowser:
      required:
          - url
      description: Holds data for an appType=Browser. It is up to the Launcher to select which Browser to use, typically this will be the default desktop browser.
      properties:
        url:
          type: string
          description: The URL to display in a browser window.
        config:
          type: array
          description: optional set of Config values for displaying the browser, for example select a Kiosk mode. Values need to be 'agreed' between Launcher and App Directrory.
          items:
            $ref: '#/components/schemas/NameValuePair'

    AppContainer:
      required:
        - manifests
      description: Holds data for an appType=Container
      properties:
        url:
          type: string
          description: |
            The initial URL of the application. This may need to be repeated in the container specific manifest. 
            We would recommend that Manifests can reference this URL via macros 
        signature:
          type: string
          description: The domain or public key that the application lives under. For example, the manifest_url would not be able to live under cdn.openfin2.co. Public Key would be a 1:1 ratio to an application but you can have many applications under a domain. Only required if app type is container.
        manifests:
          type: array
          description: |
            List of Container specific manifests for the application. 
            Maybe allow a short cut to just have a single manifest for sites with only a single container. 
            The discriminated list is of more use for companies offering an application supported in multiple containers.
          items:
            $ref: '#/components/schemas/ContainerManifest'

    AppCustom:
      description: Holds data for any other app type, it is assumed that the launcher and app directory will have agreed values to store here, outside the scope of FDC3
      properties:
        config:
          type: array
          description: The set of custom data, I prefer to give this as a list of name/value pairs with the value typically being a JSon object rather than a single value.
          items:
            $ref: '#/components/schemas/NameValuePair'

    ContainerManifest:
      required:
        - containerType
        - manifest
      properties:
        containerType:
          type: string
          description: |
            name of the Container, agreed between container vendor and launcher. 
            Should we allow companies to register standard container names like OpenFin, Autobahn or Glue42
        manifest:
          type: string
          description: |
            The application manifest for the chosen container type. 
            Should we allow companies to register standard container names like OpenFin or Glue42


Need help? Email help@finos.org we'll get back to you.

Content on this page is licensed under the CC BY 4.0 license.
Code on this page is licensed under the Apache 2.0 license.