Minutes actions review from last discussion

Frank submitted PR5 and Leslie reviewed and committed this. This was presented to the group for discussion including:

• It is a much simplified spec.
• Removed appType and appDetails of the application. Now you have manifest (URI of where the application manifest is located) and manifestType (optional right now, has a generic default of FDC3)
• These are clearly defining that the vendor will define the manifest structure and definition - that is not up to the WG. This enables flexibility so that app launchers can actually use those manifest types as templates to consume the manifest from the source.
• These are the main changes implementing the feedback from the group to simplify the spec to something that everyone can consume day one.
• Riko asked what that mean for apps not using manifests, e.g. command lines. Frank noted that a manifest can be fed through from a file, a URI can be a file or a website. It is where the detail of how to launch an application is located.
• What is this generic FDC3 type? Don’t need to define that now but this group should opine on the format and structure of this. Nick noted that you could start with the WebApp manifest.
• Examples of a non-generic FDC3 manifest could be IHS Markit, Thomson Reuters→ whatever the vendor chooses to describe their specific application.
• The group may need to define what should be in a manifest (details of how the app is launched, security, discoverability, etc.), considering a balance with what is in the appDirectory. This should not be restricted to what the WG defines, as this should have the potential to be extended by the vendor.
• Riko commented that he is okay to move forward without defining the FDC3 Manifest, as a start, and coming back this later.
• Although already committed the group can roll back if necessary. Four eyes check is always required and the group can discuss before major changes accepted.
• Riko pointed out that there is an old version of the spec listed at github.com/FDC3/App-Directory and also on the proposals on the Confluence page. Frank noted that they will clean this up and confirmed that the main one is github.com/FDC3/appd-api.

Aim is to get this specification to ratification, noting that there is still documentation to complete. Frank has also created a services to use to test

Next steps are to create a documentation page within the specification, which will describe the YAML. This then needs contributions from the group. It will be a markdown format and will incorporate the open API specification as a document within that static document set. It will also include discovery (will be moved from Confluence into GitHub). Once this is done, the group needs to agree collectively that it works as v1.0 and can be push through the normal FDC3 approval processes. The group agreed with this approach.

Riko noted that he’s recently used a tool called docusauraus, which helps generate nice documentation. Franks is using something similar called Sphinx.

Frank

Frank covered recent additions to the POC including the addition of a user rest service to support the jwt bearer token. Through the service you can create users and you can generate access tokens to access the appDirectory service. Feedback for the POC was positive.

Leslie asked when the group would start discussing the generic FDC3 schema and this will potentially be in the next meeting. Leslie should have a toolbar demo that will also work with the publisher.

There was some discussion around where generated code should be stored in the GitHub repository and the importance of having a fixed location to reference. Tick42 will provide some input on the best way to publish the npm to a public repository.

Frank will generate AppD2 to show that you can have multiple directories to consume from and add documentation discussed. This should be up in another day or two.

Frank also noted that the group needs apps and Frank will put an email out to wider FDC3 to ask for apps. The manifest type will be OpenFin for now.

Frank will work with Mao to get it this to compile properly in the FINOS GitHub, rather than IHS Markit hosting it and will also address requirement around having the FINOS namespace in the overall namespace, which it currently doesn’t have. Frank to send Rob the JIRA ticket on this.