Replies: 4 comments 6 replies
-
Note: There is an existing proposing the deprecation of the That issue should also (but doesn't yet) propose updating |
Beta Was this translation helpful? Give feedback.
-
There are some semantics to consider: Will the Fully qualified requirement for AppID be MUST or SHOULD? Without the fully qualified requirement, implementations might encounter collisions (e.g. AppId: "chart" vs. AppId: "[email protected]"). But the cost of this precision is complexity. Regarding Arguably, I would side with deprecating |
Beta Was this translation helpful? Give feedback.
-
A colleague working on our own Desktop Agent implementation (@mhmcclung) gave the below justification for the deprecation and (eventual) removal of
I note the above applies equally to |
Beta Was this translation helpful? Give feedback.
-
as |
Beta Was this translation helpful? Give feedback.
-
At the last AppD discussion group meeting it was proposed that we arrange a one-off meeting to discuss the use of the
name
field in the FDC3 API and whether that usage should be deprecated in favour of an approach based onappId
.The use of the (non-unique, machine-readable, but 'friendly')
name
field to refer to apps in the FDC3 API has long been criticised due to the fact it doesn't differentiate versions of the same app (and has no disambiguation logic) nor apps bearing the same name in different app directories. TheappId
field, on the other hand, is unique within an app directory and can be fully qualified with the domain name of the app directory that supplied it.EDIT: FDC3 2.0 deprecated API call signatures based on name and now focuses on those based on AppIdentifier (
appId
) and AppMetadata (whereappId
is required andname
optional)Beta Was this translation helpful? Give feedback.
All reactions