feat: provider metadata feature discovery#36
Conversation
Signed-off-by: Todd Baert <[email protected]>
51d9309 to
97d7ff5
Compare
beeme1mr
left a comment
There was a problem hiding this comment.
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:
Since all these are optional, we have backwards compatibility. |
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]>
beeme1mr
left a comment
There was a problem hiding this comment.
I think this proposal addresses a number of concerns we had regarding advanced features that can't be uniformly addressed across all providers.
|
|
||
| ## 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. |
There was a problem hiding this comment.
"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.
…tadata-and-feature-discovery feat: provider metadata feature discovery
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 authorswhat features are available in a particular provider.I think this would work well with badges and documentation that consistently identify features and functionality.