App Directory Discussion group - Monday 4th April 2022

[kriswest]

Group overview

Discussion group to develop proposals for the improvement of the App Directory as part of the FDC3 standard. The group will examine the role/value/necessity of the AppD as part of the FDC3 specification and a compliance requirement for use of the FDC3 API, in addition to working on proposals to improve the description and functionality of the App Directory.

Relevant tags

Current open issues and PRs that relate to the above concepts with the label:

A github discussion is also available for this group (may be used to arrange meetings, agenda ask questions etc.)

Meeting Date

Monday 4th April 2022 - 9am EST / 2pm BST

WebEx info

• Meeting Link: [insert link](https://finos.webex.com/finos/j.php?MTID=m2316d45da678d0203fd86f9342ff63ab )
• Meeting number: 2551 735 2618

More ways to join

• Join by video system:
  • Dial 25517352618@finos.webex.com
  • You can also dial 173.243.2.68 and enter your meeting number
• Join by phone
  • +1-415-655-0003 US Toll
  • +44-20319-88141 UK Toll
• Access code: 2551 735 2618

Meeting notices

• FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

• All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

• FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.

• FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

• A Discussion Group has no direct decision-making power regarding the FDC3 standard - rather it is intended that anything they propose or work on will result in proposals (via Github issues and PRs) for the Standards Working Group participants to consider and vote on for inclusion in the standard. As such, participation in a Discussion group is not required for contributing to any particular issue or FDC 2.0 as a whole.

Agenda

• Convene & roll call, review meeting notices (5mins)
• Review action items from previous meeting (5mins)
• Add backwards compatibility support for the App Directory #553 (5mins)
• Discuss issues related to 'Improving the application record' (40 mins)
  • Better align Application definition to Web Application Manifest and supplementary application information #561
  • Add categories metadata to AppD application definitions #369
  • Add language metadata to AppD for accessibility #622
  • Extend AppD application definition to support describing an app's use of interop (App Channels, User Channels & Intents) #247
  • Add details of where to get more details about an app and where to create an account #567
  • Support any App Definition so long has it has an 'fdc3' property #550
  • Add vendor-agnostic properties to the AppD application definition format for launching native apps #562
  • Add vendor agnostic default window size and position settings to the App Directory app definition format #564
• AOB & Adjourn (5mins)

Minutes

• Add backwards compatibility support for the App Directory #553

  • @openfin-johans asked whether a particular appD version (and hence URL path) would be required for compliance with a particular version of the standard as a whole
    • @kriswest commented:
      • v.10-1.2 of the standard effectively require the /v1/ URL path
      • the new /v2/ URL path would be required for compliance with the matching standard version (2.0+) (MUST)
      • the old /v1/ path would then become optional (MAY) so that a single installation can support clients on either version.
      • Compliance info in the standard is to be improved and should be clarified on this point at the same time.
  • @nkolba commented that:
    • we might need a way to ask/discover what versions of the AppD (and URL path) are supported by an appD instance
    • we may wish to consider adding a new generic, version agnostic endpoint that points to the most recent version supported if the version is omitted from the URL path
    • we need further discussion of versioning information and procedures throughout the FDC3 standard...
      • @kriswest suggested this as an action item for the Standards Working Group, and perhaps post-2.0 (as 2.0 is set to update all 4 parts of the standard)
  • silent consent was sought for implementing the new /v2/ URL path: no objections were raised

• Better align Application definition to Web Application Manifest and supplementary application information #561

  • This issue precipitated discussion of optional and required use-cases for the AppD and wether we should be considering them.
    • @lspiro-Tick42 and @kriswest both spoke about the importance of the 'App portal/catalog/store' use-case for appD data.
      • Having the information available to render such an interface well may be a secondary use-case to providing configuration for interop (details of intents) but it is nevertheless important.
      • It is also already used to render a resolver UI for raised intents
      • The group affirmed that these were important use-cases - however it was noted that:
        • we should not import anything from the Web Application manifest that we do not need.
        • only the bare minimum fields should be required (MUST), with additional metadata being recommend (SHOULD)
  • The balance of opinions was sought on wether to proceed with this issue: 5 participants were for proceeding, none were against

• Add categories metadata to AppD application definitions #369

  • change tags to categories to align with Web Application Manifest
  • recommend (SHOULD) some initial categories (remembering to check the Web Applicaiton Manifest spec for any applicable categories)

• Add language metadata to AppD for accessibility #622

  • @kriswest summarized the issue and how it prevents the addition of either localisation or accessibility (screen reader support) to an app rendering AppD content
    • A question was raised as to whether this should be deferred until further work on localizing or adding support to FDC3 as a whole can be considered.
      • @kriswest commented that, on review of the standard, it appears that data delivered from the AppD is the only issue in standard (other than the standard's own website).
    • @kriswest additionally commented that there was an intention to extend the issue to the provision of translated versions of an appD record as an optional field within the record
      • This idea received support from a number of participants and was considered preferable to providing separate alternative records within an appD.
  • silent consent was sought for moving this issue to a PR (to include both the proposed lang field)
    • no objections were raised

• Extend AppD application definition to support describing an app's use of interop (App Channels, User Channels & Intents) #247

  • A brief overview of the issue was provided, including:
    • the detail that Extend AppD application definition to support describing app channels and their purpose #371 was merged into it
    • the fact it enables a UI rendering AppD contents to display apps that 'work with' a selected app
    • it would be optional additional metadata
    • it also provides a place for developers to get at this information, without having to rely on published documentation for a product.
  • @nkolba
    • that there may be a danger to including too much info, in case it becomes stale...
    • what about manually creating links, via a relatedApps element?
      • @kriswest: this is more fragile and harder to maintain (each link is data on two apps rather than one) and its hard to do cross-directory (you could work with multiple appDs, including those hosted by vendors)
      • dynamic links through this data have clear advantages
      • slight naming clash with another issue to be raised (listing related or prerequisite apps in an appD record)
  • The end of the meeting curtailed discussion on this issue - all were asked to review the issue before next meeting.

• @nkolba noted that we also need to discuss some issues with the use of the appId vs. name fields and the use of name vs. AppMetadata in the API (see issue Deprecate use of the string name field in favour of AppMetadata #506)

  • @kriswest suggested that, given the timeline for FDC3 2.0, it might be best to arrange a meeting of interested parties to collaborate on a proposed change to raise at a future SWG meeting.

Action Items

• @ggeorgievx and @kriswest Raise a PR to resolve Add backwards compatibility support for the App Directory #553
  • add a /v2/ URL path to the AppD spec as required (MUST) and to restore/retain the /v1/ URL path and record format as an option for backwards compatibility
• @kriswest Raise a PR to resolve Better align Application definition to Web Application Manifest and supplementary application information #561 by
  • Aligning/renaming current fields that replicate Web Application Manifest fields
  • Adding a statement about the alignment to the documentation
• @kriswest Ensure other open issues and PRs are aligned with Web Application Manifest
• @kriswest Raise a PR to resolve Add categories metadata to AppD application definitions #369
• @kriswest Raise a PR to resolve Add language metadata to AppD for accessibility #622
• ALL review extensions proposed in issue Extend AppD application definition to support describing an app's use of interop (App Channels, User Channels & Intents) #247
• @nkolba & @kriswest arrange an ad-hoc meting to discuss appId vs. name use in the API and raise an issue to represent the need for change
• @kriswest Add to future meeting agendas:
  • making a decision on Extend AppD application definition to support describing an app's use of interop (App Channels, User Channels & Intents) #247
  • Add details of where to get more details about an app and where to create an account #567
  • Support any App Definition so long has it has an 'fdc3' property #550
  • Add vendor-agnostic properties to the AppD application definition format for launching native apps #562
  • Add vendor agnostic default window size and position settings to the App Directory app definition format #564

Untracked attendees

Full name	Affiliation	GitHub username

[Julia-Ritter]

Julia / FINOS

[openfin-johans]

Johan / OpenFin 🎁

[kriswest]

Kris / Cosaic 🚀

[hampshan]

Andrew / UBS

[robmoffat]

Rob / FINOS

[tpina]

Tiago Pina / Cosaic

[ggeorgievx]

Georgi / Tick42

[nkolba]

Nick / kolbito

[lspiro-Tick42]

Leslie Spiro / Glue42

[hughtroeger]

Hugh / FactSet

[mistryvinay]

Vinay / Symphony

[jgavronsky]

Jane @ FINOS here

[robmoffat]

One action I took from this meeting was to review the app manifest and compare it to some others.

• Clearly, PWA is a big inspiration to the group already: https://developer.mozilla.org/en-US/docs/Web/Manifest

• Here is the Symphony app manifest, for example: https://docs.developers.symphony.com/building-extension-applications-on-symphony/app-configuration/application-manifest-bundle-file-reference.

• Here is the Microsoft Teams manifest: https://docs.microsoft.com/en-us/microsoftteams/platform/resources/schema/manifest-schema

• Couldn't find any official documentation, but here is a list of requirements for Apple Store: https://www.ideamotive.co/blog/how-to-get-an-ios-app-on-the-app-store

• Some details about what is required for Google Play Store: https://support.google.com/googleplay/android-developer/answer/9859152

Some ideas to consider:

• OBO (On-Behalf-Of) permissions. i.e. things that the app can do on behalf of the user installing the app (unless this is already covered and I don't know about it)
• Preview images of what the app looks like in action
• Translations: Information about which languages the app is translated into
• Instructional videos
• Support details