Skip to end of metadata
Go to start of metadata
(Note: Agenda and minutes of this meeting were very late and do not reflect the entire discussion)
Attendees
| Name | Organization |
|---|
| IHS Markit |
| OpenFin |
| OpenFin |
| Tick42 |
| Riko Eksteen | JPMorgan |
| Georgi Georgiev | Tick42 |
| FINOS |
| FINOS |
Discussion items
| Time | Item | Who | Notes |
|---|
| 5min | Minutes actions review from last discussion | All |
|
| 15min | Documentation publication and specification | All | Frank presented changes around the documentation including: - new folder in FDC3/appd-api called docs, which is where the actual specification and documentation will reside.
- GitHub Pages functionality then produces a website, which in future will be consistent across all of FDC3.
- Now incorporates the AppD Discovery with important information and diagrams.
- Intention to add a folder on usage in future to provide, e.g. an example of how you would use the AppD within a workflow so that someone using the specification can really understand what discovery means, the structure of the data that comes back, etc
- Initially used ReDoc to publish a complete single HTML page with the specification and navigation included but will work with Maurizio from FINOS to converge to the cross-FDC3 efforts on this front.
- Recommended that comments on/changes to the documents be made by making a PR to the specific files in the docs site.
- Noted that if you are changing/commenting on the specification you should go to the appd.yaml file and submit a PR.
- The other FDC3 repository will be archived to reduce confusion.
The group agreed it was okay to publish this first iteration and comments can be made for changes going forward. Frank requested that the group review the documentation and help ensure it is clean. Other points discussed - There is overlap between a number of the WGs, particularly in FDC3, and it's important to make the overall context accessible.
- There should be a single "root" site that provides understanding of the overall FDC3 program and navigation to more specific areas.
|
| 20min | Tick42 Launcher demo (documentation coming) | Leslie
| Leslie was nice enough to demonstrate a desktop launcher that is integrated with the AppD POC. Discussion included: - Showed the launcher toolbar that Tick42 is getting ready to contribute and impact to context definition
- Ran Frank's demo app and self-contained Electron app (no Glue42 in this demo) to show the interaction between apps
- The launcher is independent of any platform (e.g. Glue42, OpenFin) and uses the AppD to identify applications to open.
- This led to discussion around platform and manifest.
- Frank suggested that the launcher demonstration is a good example of how the AppD implementation can be used
|
| Remainder | Manifest discussion and specification ratification (v1) | All | The group discussed the FDC3 manifest. Discussion items included: - Frank highlighted some of the elements in an original "bare bones" OpenFin manifest (screenshot below), including parts like startup_app and runtime to look at required contents, not looking at the attributes just some of the main elements. Although this structure is specific to a web-focused run-time but you can be abstract those parts.
- Leslie stated that his preference is to use appDetails that was used previously (exe, browser, custom, etc.)
- Frank noted that the manifest itself is supplied by the vendor or app publisher and the group wanted to provide an area where someone could identify what that manifest is in terms of structure and so manifest could be a URI or JSON blob. manifestType attribute would describe how an application should read that information.
- The previous yml included AppExe and AppBrowser, which Leslie was in favour of keeping in the FDC3 manifestType.
 - Riko noted that, arguably, you could get by with a classification and a string.
- There was continued discussion around what is returned from the AppDirectory, how to start the application, what is the difference between the various types, what goes into appDetails and more.
- Agreed that Leslie could create FDC3.demo.manifest as a type to use as an example manifest.
- Agreed to remove the default for manifestType as there is no agreed definition and standard but manifestType will be mandatory but with no default. (The changes were implemented real time.)
- All felt the need to get to a very basic v1.0.0, so keeping it simple made more sense.
The group agreed to move forward with the approval (ratification) process via email of version 1.0.0, labeled as such and with the documentation. Frank took ownership of pulling together first official draft specification (written form) and asked everyone to provide comments offline with a vote to be done through email. |
Action items
Tasks Identified and Assigned
Task Report from Last Meeting
Task report
Looking good, no incomplete tasks.