562 AppD vendor agnostic native apps

[kriswest]

resolves #562

Introduces launch details for native application types and adjusts the standardized application types to accommodate. Also adjusts the relationship between type, details and hostManifests by eliminating the host application type and allowing hostManifests to override details if they want/need to. I believe this makes the (vendor agnostic) details field more useful and more likely to be used than if it is simply ommited when a hostManifest is used. This allows details to become a required field.

Documentation example:
EDIT: see updated example in comment thread instead

Change was agreed in principle (but not in detail) at meeting:

• App Directory Discussion group - Tuesday 19th April 2022 #664

[kriswest]

@ggeorgievx here's an initial proposal for vendor-agnostic native app launch details and the tweaks I mentioned to the type/details/hostManifests relationship.

Base of the PR is wrong, but have set it up this way so you can see just these changes. Will change the target when we're agreed on it.
EDIT: targeting consolidated update branch.

In particular, can you check the citrix launch args against what you use?

To run the thing locally run the following in the website folder:
yarn prebuild; yarn build; yarn start

then take a look at: http://localhost:3000/schemas/next/app-directory#tag/Application/paths/~1v2~1apps/post

[ggeorgievx]

@kriswest LGTM! Thank you for clarifying the relationship between hostManifests and details!

Two minor things:

• should we add a comment about DAs that don't support certain types of applications?
• should we leave the host application type to allow for other application types?

[kriswest]

@ggeorgievx

• should we add a comment about DAs that don't support certain types of applications?

Good idea. We could either:

• State that at least one application type MUST be supported, but any subset MAY be supported.
• State that at least the Web type must be supported, while other types MAY be supported.

I'm leaning towards the latter as interop between web and other apps types is what I think most would expect of a 'FDC3 compliant' desktop agent and I know of no implementations that don't support web apps...

• should we leave the host application type to allow for other application types?

A good point - although I might prefer and other type for that and state that its details would have to be defined by a hostManifest? The first example that springs to mind is something like a python app, but I suspect you could still handle that as native and start with a path and arguments...
What your preference here?

[ggeorgievx]

@kriswest

I'm leaning towards the latter as interop between web and other apps types is what I think most would expect of a 'FDC3 compliant' desktop agent and I know of no implementations that don't support web apps...

I agree with you.

A good point - although I might prefer and other type for that and state that its details would have to be defined by a hostManifest?
...
What your preference here?

Happy to rename host to other. This would give DAs the flexibility to provide other, custom application types e.g. a node (Node.js) application type that uses the internal, Electron Node.js runtime.

As both changes would require minimal changes I suggest we raise this at the next AppD WG.
I am also adding @donbasuno as a reviewer to run everything by his team.

[kriswest]

Heres what it looks like after that last change (to simplify review):

My only outstanding question is whether path & arguments is enough for native apps (and url for online native) or whether we need to support some sort of appAsset and alias combo.

[ggeorgievx]

My only outstanding question is whether path & arguments is enough for native apps (and url for online native) or whether we need to support some sort of appAsset and alias combo.

From our side path + arguments is sufficient. Thank you @kriswest!

[ggeorgievx]

My only outstanding question is whether path & arguments is enough for native apps (and url for online native) or whether we need to support some sort of appAsset and alias combo.

From our side path + arguments is sufficient. Thank you @kriswest!