Skip to content

feat: provider metadata feature discovery#36

Merged
toddbaert merged 4 commits intomainfrom
feat/provider-metadata-and-feature-discovery
Nov 16, 2022
Merged

feat: provider metadata feature discovery#36
toddbaert merged 4 commits intomainfrom
feat/provider-metadata-and-feature-discovery

Conversation

@toddbaert
Copy link
Copy Markdown
Member

@toddbaert toddbaert commented Nov 14, 2022

Mostly brought up based on comments in the events OFEP, this OFEP proposes a solution for "feature discovery" in the context of providers, in order to signal to the SDK and application authors what features are available in a particular provider.

I think this would work well with badges and documentation that consistently identify features and functionality.

@toddbaert toddbaert force-pushed the feat/provider-metadata-and-feature-discovery branch from 51d9309 to 97d7ff5 Compare November 14, 2022 18:24
Copy link
Copy Markdown
Member

@beeme1mr beeme1mr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add a section that talks about backwards compatibility? I would expect new features to be optional and require the provider developer to explicitly add support for the feature.

@toddbaert
Copy link
Copy Markdown
Member Author

Could you please add a section that talks about backwards compatibility? I would expect new features to be optional and require the provider developer to explicitly add support for the feature.

I think that's covered by the phrasing:

...be extended to include optional properties that denote which features are available on the implementing provider...

Since all these are optional, we have backwards compatibility.

@beeme1mr

toddbaert and others added 3 commits November 14, 2022 14:23
Co-authored-by: Michael Beemer <[email protected]>
Signed-off-by: Todd Baert <[email protected]>
Signed-off-by: Todd Baert <[email protected]>
Signed-off-by: Todd Baert <[email protected]>
@toddbaert toddbaert requested a review from beeme1mr November 14, 2022 19:30
Copy link
Copy Markdown
Member

@beeme1mr beeme1mr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this proposal addresses a number of concerns we had regarding advanced features that can't be uniformly addressed across all providers.

@toddbaert toddbaert merged commit 59fd042 into main Nov 16, 2022

## State: DRAFTING

This OFEP proposes a solution for "feature discovery" in the context of providers, in order to signal to the SDK and `application authors` what features are available in a particular provider.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"feature" is quite an overloaded word in the domain of open feature. For the sake of sanity, could we use "capability" instead? We'd use capability discovery to discover which capabilities a given provider has. Language like "does this provider support the provider events capability" seems pretty natural to me.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great point, love it.

weyert pushed a commit to weyert/research that referenced this pull request Jan 31, 2023
…tadata-and-feature-discovery

feat: provider metadata feature discovery
@beeme1mr beeme1mr deleted the feat/provider-metadata-and-feature-discovery branch May 11, 2023 02:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants