Skip to end of metadata
Go to start of metadata
Attendees
Name | Organization |
---|
| IHS Markit |
| OpenFin |
| Tick42 |
Georgi Georgiev | Tick42 |
| FINOS |
Discussion items
Time | Item | Who | Notes |
---|
5min | Minutes actions review from last discussion | All | Minutes were not ready to be approved. |
5min | Update on ratified spec and focus going forward | All | Ratified Spec Frank noted that the WG approval of the AppD specification had been socialized and was available for comment for the required two week review period (actually three weeks). There were no comments and so the specification was ratified by the PMC on 30 Nov 2018. Follow-up steps include: - Change versioning
- Show that it is ratified and then re-post
- Add client bindings (Frank is publishing a release version of the bindings for Java and help on others is needed)
- Leslie to make updates to the ReadMe by doing a PR with the changes.
- Next version will be 1.0.1
Discussion on next focus areas - Frank presented at the OSSF FDC3 meetings that focus was on:
- Eventing
- Search capabilities, surfacing other content
- Data itself - what other capabilities
- Manifest format detail (describing the content)
- Identity and authentication
- Leslie asked about app store vs appDirectory, which can be a topic for future conversation
- Asked the group about any other items and prioritizations? Group agreed on these priorities:
- searching
- manifest
- eventing
Discussion on Search (includes search and filtering) - How to approach → what are we searching for? Application is the only key model and within that there are lots of attributes. Can we create a search capability to search all attributes of the definition of the model? Leslie → the use case is around intents and context and if we have a generic search then that’s great. Most relevant incremental search so you can do type ahead.
- Use SQL or Graph SQ
- Could lock down or search anything. E.g., someone might want to search on image description so should we limit the types of searches that we allow users to do. And how is this represented in the specification.
- if you want to type ahead on an app name. You might want special support for some searches, like the type ahead on name and intents and context
- Do you need to search on contact or support email? Maybe.
- Frank to present on how postgreSQL covers relevant queries.
- GraphQL is also an option, potential issue is it’s a completely different interface definition.
- Allow everything to be searched but not be heavy handed. The concern might be on performance.
- Next step is to document what we want in a search and turn this into a proposal. We could provide a GraphQL definition. It might also fit in with manifest structures. The minimum requirement is to search on basics. We can also accept counterproposals.
- Frank would like AppD to have a feature to support manifest.
|
30min | FDC3 documentation and overall picture | All | There was a brief review of the FDC3 plan, looking through personas and web properties. Everyone should review the list of docs/gaps. Where PMC is assigned, this is where we need to go back and do some work as it's really important to showcase how the wider community can use FDC3. |
Remainder | AOB | All | Launcher Demo Leslie noted that Tick42 has a toolbar demo running an FDC3 implementation. Frank agreed it's valuable to have a reference implementation and there is space for this in the spec. The group also agreed it would be okay to host an example video showing how the specification addresses interoperability. Demo should be pushed to: https://github.com/FDC3/appd-glue42-launcher-poc
No meeting on 2nd January 2019. |
Action items
Tasks Identified and Assigned
Task Report from Last Meeting
Task report
Looking good, no incomplete tasks.