Interest in the Flag Definition Language?

[sighphyre]

There's been quite a lot of chatter on the topics Flag Definition Language, Flag Evaluation Wire Protocol and the In Process Flag Evaluation. The Flag Evaluation Wire Protocol seems to be moving but myself and Unleash at large are probably more interested in the Flag Definition Language and In Process Flag Evaluation topics.

I know there's been some interest in using Unleash's Yggdrasil for this (disclaimer: I'm the author of that project), but I feel we should explore options before we settle.

So I'd like to start gathering ideas for this and seeing what ideas others have for this and if there's still interest.

[cosmic-flood]

Can you explain more about it?

Based on the information you provided, I'm not interested, and I don't agree with all of the design elements of Unleash's flag evaluation, even though it's used by many companies. For example, as discussed in an article on their website (https://www.getunleash.io/blog/streaming-flags-is-a-paper-tiger).

OpenFeature helps us avoid vendor lock-in by standardizing the interface of the SDK, but not its flag evaluation process. The flag evaluation process should be diverse across different providers.

[dgorton]

Thanks for the feedback! As some additional context, this conversation started in another discussion from @toddbaert in https://github.com/orgs/open-feature/discussions/249 and was continued over Slack and in the project meetings (notes)

Two highlights from that initial post:

Defining a flag definition language could amount to publishing a JSON schema which defines a structure for a set of flags (we already do something similar in the flagd project).

PaaS providers and infrastructure as code solutions could leverage a consistent flag definition language to define flags in a vendor neutral way.

The conversation has continued and there's one effort that's looking more deeply into what the initial post called a "flag evaluation wire protocol" although the name has adjusted over time. This thread is to explore the other side of the Todd's initial proposal.

In this context, the Yggdrasil library could be adapted in part or whole as a part of the flag definition language. I don't think anyone expects that this would be a quick process, but the code and DSL are at least an interesting example for what this might look like in the real world. If you want to read more about how the Unleash team got there, this blog might be interesting: https://www.getunleash.io/blog/yggdrasil-unleash-flag-evaluation-engine

Either way, thanks for the feedback!

[beeme1mr]

Hey @cosmic-flood, as @dgorton mentioned, the idea of exploring a potential common flag definition started last year. The goal was to see if there was a way to define a flag structure that was capable of supporting the most common use cases. That would allow us to create a single provider that could fetch the flag configuration from any source that supported the flag definition. This would reduce the burden on provider maintainers and allow tools/vendors to potentially work with technologies where they don't have an official SDK. The current provider model would remain in place.

Interest in a common flag definition was mixed. I think there's a lot of potential but the road to get there will be challenging. For now, the OpenFeature GC has decided to focus on the remote evaluation protocol. However, I'm hoping this GitHub discussion can be used to gauge community interest.