App Directory Discussion group - Tuesday 19th 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

Tuesday 19th April 2022 - 9am EDT / 2pm BST

WebEx info

• Meeting 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)
• Discuss issues relating to 'Improving the application record' (20mins):
  • 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
• Discuss issues relating to 'Improving the AppD API' (25mins):
  • Improve the AppD's search function and documentation #370
  • Introduce a new fdc3.applications() method #311
  • Make it possible to retrieve all applications in an AppD #565
  • Add pagination support to AppD APIs #557
  • Endpoints for adding an app to an appD will often be implementation dependent and should not be required for compliance #566
  • Provide better documentation and examples for AppD auth support #559
• Discuss other issues (if time):
  • The AppIntent interface incorrectly describes an intent #312
  • Create an AppD reference implementation #563
• AOB & Adjourn (5mins)

Minutes

• Add backwards compatibility support for the App Directory #553
  • @ggeorgievx and @kriswest are working on a PR to enable an appD to host both /v1/ and /v2/ URLs
    • 553 Support v1 and v2 URLs in AppD spec #666
• Better align Application definition to Web Application Manifest and supplementary application information #561
  • Work to align open PRs and existing appD fields with the Web Application Manifest is ongoing and will result in PRs for future meetings to review.
• Extend AppD application definition to support describing an app's use of interop (App Channels, User Channels & Intents) #247
  • @nkolba raised a number of questions about the goal of this issue - which @kriswest clarified as: to provide optional metadata about an app's use of interop to enable interfaces that view appD data (e.g. an app store-like interface) to be able to find apps that 'work with' other apps. A secondary goal is to provide a standard place to advertise this info for developers wishing to integrate with a particular app (without having to research that apps own documentation).
  • Specific questions:
    • Can app channels be private/obscure?
      • yes, declaration in this config is optional
    • Does this metadata imply a contract with the DA?
      • No. It is entirely optional and intended to be used by a UI viewing the appD, rather than the desktop agent.
    • User channels is a bit confusing, maybe just declare broadcast/listen
      • A number of the firms publishing DA implementations have found that developers getting started tend to confuse User channels and App channels (e.g. by trying to 'join' an app channel). Hence, keeping these differentiated in the metadata is likely also important.
    • Intents in two places in the config is confusing (existing element for intents resolved, while this adds an element for intents raised). Intents appearing under an element named contexts is also confusing.
      • @kriswest to take another pass at the proposed additions and attempts to find a more intuitive set of names which clarifies that this is optional metadata and.
  • Consent was sought for this issue to proceed (i.e. that the addition makes sense) - No objection were raised and there was general agreement that this was a sensible extension
• Add details of where to get more details about an app and where to create an account #567
  • Consent was sought for adding a 'more info' field to the appD record - no objections were raised.
• Support any App Definition so long has it has an 'fdc3' property #550
  • Brief summary of this issue was provided.
  • No one was available to speak for this issue.
  • Proposed to leave it open until next meeting and then close it if there is no further activity. @kriswest to add comment to the issue to make the author aware.
• Add vendor-agnostic properties to the AppD application definition format for launching native apps #562
  • @thorsent host manifest already contains information that is proprietary
    • In the current draft you would use type: “host” to point to host manifest for launching info, however this is vendor specific
    • @ggeorgievx We could/should collect examples of existing use cases and app launch types (e.g. from Cosaic/G42)
    • @nkolba an alternative to adding this complexity to the appD record might be extension of appD API, rather than the record. What was the problem with the the old manifest and manifestType fields?
      • @kriswest: manifest could only hold a single (string encoded) manifest, so you needed multiple copies for different containers, which should be avoided. Also if we deliver different manifests based on user agent or parameters were shifting complexity to people who have to maintain records and appD implementations which isn't a better situation.
    • Some discussion ensued over the type field - a value of host points to the hostManifests, however it may make more sense to allow 'hosts' to look for manifests that they are expecting and instead use this field to differentiate app types with values such as web, native, citrix, clickonce etc.
      • @ggeorgievx and @kriswest to take a pass at refining type and details fields after reviewing app types their respective products support launching and what details are necessary.
• Add vendor agnostic default window size and position settings to the App Directory app definition format #564
  • This data is currently handled by hostManifests, while the Desktop Agent API avoids dealing with 'window management'
  • Web Application Manifest includes some detail on orientation and window type, but not on dimensions
  • This issue is not urgent and might be better resolved once more appD's have been published and can be drawn on for common fields.
    • There was general consensus that this should be removed from the 2.0 scope, but left open for resolution in a later version.

Action Items

• @kriswest Refine issue Extend AppD application definition to support describing an app's use of interop (App Channels, User Channels & Intents) #247 proposal (and rename the contexts element)
• @kriswest Implement PR to add moreInfo field to resolve Add details of where to get more details about an app and where to create an account #567
• @ggeorgievx and @kriswest raise a PR to refine the type and details field and resolve Add vendor-agnostic properties to the AppD application definition format for launching native apps #562
• @kriswest Add to future meeting agendas:
  • Support any App Definition so long has it has an 'fdc3' property #550 (close if no further activity or interest)
  • Discuss issues relating to 'Improving the AppD API' (25mins):
    • Improve the AppD's search function and documentation #370
    • Introduce a new fdc3.applications() method #311
    • Make it possible to retrieve all applications in an AppD #565
    • Add pagination support to AppD APIs #557
    • Endpoints for adding an app to an appD will often be implementation dependent and should not be required for compliance #566
    • Provide better documentation and examples for AppD auth support #559
  • Discuss other issues (if time):
    • The AppIntent interface incorrectly describes an intent #312
    • Create an AppD reference implementation #563
• Rolled over from previous meetings:
  • @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
  • @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

Untracked attendees

Full name	Affiliation	GitHub username

[Julia-Ritter]

Julia / FINOS

[Soul-Master]

Sumit / LSEG

[WatsonCIQ]

Chris Watson / Cosaic

[bertrand-s]

Bertrand / Symphony

[ggeorgievx]

Georgi / Tick42

[tpina]

Tiago Pina / Cosaic

[nkolba]

Nick / here

[derekdon]

Derek Donnelly / Genesis