• We may want to implement another function to "re-initialize" the configured provider, which would again put it in a ready state.

This doesn't seem necessary. You could just reregister a provider to reinitialize a provider that was shutdown.

This doesn't seem necessary. You could just reregister a provider to reinitialize a provider that was shutdown.

I had the same thought. We could do it this way, but re-registering the same provider feels a bit odd. Maybe it actually makes the most sense though. I don't feel too strongly about that one either way.

• I think both Support in spec for closure/shutdown spec#163 and this OFEP suggest adding the shutdown method to the client. I think instead it should be added to the top-level API object, (ex: OpenFeatureAPI.shutdown()). My reasoning for this is because this would shut down the provider, which would impact all clients. Because the effect is global, I think it should be implemented on the global object.

This is really interesting. I hadn't experienced a use case of multiple clients simultaneously consuming one provider and one OpenFeatureAPI but your suggestion makes sense in light of that capability and use case. I agree that it makes the most sense to ensure a shutdown call closes all clients.

• I think both Support in spec for closure/shutdown spec#163 and this OFEP suggest adding the shutdown method to the client. I think instead it should be added to the top-level API object, (ex: OpenFeatureAPI.shutdown()). My reasoning for this is because this would shut down the provider, which would impact all clients. Because the effect is global, I think it should be implemented on the global object.

This is really interesting. I hadn't experienced a use case of multiple clients simultaneously consuming one provider and one OpenFeatureAPI but your suggestion makes sense in light of that capability and use case. I agree that it makes the most sense to ensure a shutdown call closes all clients.

OpenFeature is currently designed that you can only have a single instance of the API, and one or more clients. So the case of many clients will need to be handled.

This doesn't seem necessary. You could just reregister a provider to reinitialize a provider that was shutdown.

I had the same thought. We could do it this way, but re-registering the same provider feels a bit odd. Maybe it actually makes the most sense though. I don't feel too strongly about that one either way.

I think registering a provider makes sense. I am doubtful registering the same provider (as in same instance) would make sense, as the provider would already be closed, so you would still need some means to tell it not to be closed. (The way my provider currently works, if it were to be closed somehow, then it couldn't really be started again.)

I think registering a provider makes sense. I am doubtful registering the same provider (as in same instance) would make sense, as the provider would already be closed, so you would still need some means to tell it not to be closed.

Great point. If some providers implement a means of "re-initialization", I think that's their business, and we can leave the SDK out of it. The SDK will simply use whatever provider is set, and if the state of readiness is maintained with the provider, we don't need to define "re-initialization" behavior on the SDK.

@jakedoublev with regards to multiple clients, this bit of doc may be helpful.

Hey @weyert, would you be able to address the feedback and sign off your commits? This is a pre-req for some upcoming client-side changes. Thanks!

Hey @weyert, would you be able to address the feedback and sign off your commits? This is a pre-req for some upcoming client-side changes. Thanks!

I have applied the suggestions and signed them off. I will have a closer look what is needs to be done based on the comments

@weyert if you give me access to your fork, I can push the contents here up to it, and then we can revive this PR. Let me know!