-
Notifications
You must be signed in to change notification settings - Fork 0
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we want a "context-aware evaluation" section as well here, similar to this
README.md
Outdated
### Providers: | ||
|
||
To develop a provider, you need to create a new project and include the OpenFeature SDK as a dependency. | ||
This can be a new repository or included in [the existing contrib repository](https://github.com/open-feature/java-sdk-contrib) available under the OpenFeature organization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is linking to the java sdk contrib now. We'll need to wait for the kotlin contrib location to be ready before adding it to the documentation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's another place in the readme that links to Kotlin repo (which isn't populated yet) - let's keep in mind to update these upon release.
// get a bool flag value async | ||
coroutineScope.launch { | ||
WithContext(Dispatchers.IO) { | ||
client.awaitProviderReady() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we use the "raw" eventObserver
here, and remove this helper function "awaitProviderReady"? It looks nice, but it's not in the OpenFeature Specs, and it adds more ways for users to wait on Provider's readiness, while it's probably nice to have a single way to achieve this using just events
Updating README.md using OpenFeature-provided template.