Logging configuration

[toddbaert]

We may want to define a standard logging interface that could be supplied as an optional argument to the client creation function, which could wrap standard logging functionality of the implementation language (or whatever the Application Author wants to use).

[agentgonzo]

It'll certainly be nicer than directly using its own logger, which just happens to be a different one from the logger that the caller is using.... which happens all the time 😆

[toddbaert]

It'll certainly be nicer than directly using its own logger, which just happens to be a different one from the logger that the caller is using.... which happens all the time laughing

Yep, and it's always irritating 😡.

Using it's own logger, or just writing to console could always be a fallback to one being un-supplied.

[toddbaert]

We should also give providers access to the logger somehow, I think. The can use it in provider logic, but also, pass it to whatever SDK they might be wrapping, if that's supported.

[moredip]

An intentionally provocative idea - what if we didn't specify any logging support at all, and relied on otel integration for this capability?

Or, less provocatively, could we implement logging entirely in userland via hooks?

[toddbaert]

An intentionally provocative idea - what if we didn't specify any logging support at all, and relied on otel integration for this capability?

Or, less provocatively, could we implement logging entirely in userland via hooks?

Point one is provocative indeed, not sure yet how I feel about that.

I'm interested in the second point as well, it might be enough, but does that get us all the logging we need? What if there's a desire to log something IN a provider, or in the basic flag evaluation life-cycle outside a hook?

[toddbaert]

An OFEP for this would be good, eventually.

[beeme1mr]

I'm going to move this to the research repo.

[toddbaert]

We've decided that logging is enough of an orthogonal concern that we will not outline it in the spec.

It will be up to SDKs to implement logging in a language-idiomatic way, keeping in mind the applicable design principles.