Support for parameterized urls in the AppDirectory and Desktop Agent

[kemerava]

Enhancement Request

Being able to have the record in the app directory that would have the part that would be replaced dynamically by the desktop agent with the context. For example, "https://example.com/{{context}}" or "https://example.com?context={{context}}"

Use Case:

Being able to use deep links provided by the application to launch different pages of the application

Workflow Description

App A will send the request to essentially open with context, and if the url is parametrized, then in the app directory, then instead of doing the current workflow, it would replace the part of the url and launch it that way

[novavi]

@kemerava I like this idea! In previous work when integrating non-FDC3 apps with FDC3 apps, I had listeners at platform level to translate FDC3 intents into concrete urls in order to launch the non-FDC3 apps with route params / querystring params... but I really like your idea of supporting this type of functionality directly in the app directory and fdc3.open(..).

Some purists might perhaps say that non-FDC3 apps should simply be upgraded to support FDC3, but in the real world pragmatism can be necessary - particularly when dealing with apps provided by different owners/vendors. The good thing about your proposal is that it allows incremental adoption of FDC3 across an ecosystem of apps. For example, if a (non-FDC3) target app was subsequently upgraded to support listening for FDC3 contexts (and it's app directory record changed to remove the tokenized parameters from the url), then the source app should probably not need any change - it could continue to call fdc3.open(..) and would not need to concern itself with how the context was actually delivered to the target app.

I think your proposal would work as-is (albeit with some further fleshing-out after it's been discussed at the WG). However, it might be instructive to consider and debate the merits of supporting multiple parameters in the tokenized urls. For example:

https://example.com?isin={{context.id.ISIN}}

https://example.com?someProp={{context.prop1}}&someOtherProp={{context.prop2}}

https://example.com/{{context.prop1}}/{{context.prop2}}

I would concede that this would add more complexity to the proposal. It would necessitate decisions on the behaviour in the case where context paths could not be parsed e.g. raise an error (OpenError.ErrorOnLaunch or perhaps a new, more specific enum value) or pass an empty value... there are probably differing views on what the behaviour should be here... and perhaps the source app could even specify that required behaviour.

The main reason I think it's at least worth discussing the above is that it could potentially allow integration of non-FDC3 target apps without any code change in those apps - which could particularly helpful in the case of a target app provided by a 3rd party vendor (where there is no direct control over the prioritization of even a simple context-parsing app change that sits in their backlog).

Regardless of my above suggestion, I believe your original proposal still adds a lot of value as-is.