Previously created clients should always use currently registered provider about spec

[justinabrahms]

I was actually thinking of a world where we had multiple clients, one for each provider. This would allow me to have a config-backed provider and a service-backed one. I might also have a single aggregate provider, but would need to do something w/ FlagEvalOptions to make it work.

Would love to better understand the use-case you're seeing w/ updating the provider to be different and have it reflect in existing clients.

[toddbaert]

@justinabrahms

Thinking about what you wanted more, I think one (possibly nice) way to do that would be to utilize "namespaced" providers...

Basically, we'd add an optional namespace param to the setProvider() call:

OpenFeature.setProvider(new MyGlobalProvider()) // general provider

OpenFeature.setProvider(new MySpecificProvider(), "admin-pages") // admin-pages represents one logical section of some app that wants to use a different feature-flag control plane than the rest of the app

then:

OpenFeature.getClient({  nameSpace: "admin-pages" }) // returns a client associated with MySpecificProvider

Does this make sense? I think this makes the behavior pretty clear, the implementation would be very straightforward (maintain a single map of providers with keys being the namespace), it doesn't complicate basic use cases, and I think it supports your goal.

cc @beeme1mr

[toddbaert]

I think this discussion might merit a meeting, either during our standing one, or something dedicated.

[justinabrahms]

I think I like that. My preference is we leave this ticket open until post-alpha bc this doesn't seem necessary to hit that goal and I want a stable spec to shoot for. :)

Or maybe we tag an alpha spec that I can work towards.

[toddbaert]

I'm going to close this now, and we can revive it if it comes up again... I think it's a bit of an edge case.