Proposal for session flag consumption

[Martin Lindsay]

I put together a generalized approach for passing flags, a sort of Once And For All for how to pass session controlled from to the platform. Wanted your folks' take on it. I can always fashion another one-off in the SDK for it, but I'd rather ease this path for the future.

go/fuchsia-product-flags

Thanks

[Adam Barth]

Hi Martin,

Thanks for working on this problem. I agree the current approach isn't scaling well.

Would you be willing to use the go/fuchsia-rfc-process? That's the way we prefer to make these sorts of system architecture decisions.

In terms of technical feedback, the component framework has a configuration system based on configuration capabilities. I'm curious whether you considered an approach where we pass the product configuration as a dictionary of configuration capabilities. That would have certain advantages, such as the ability to route the various configuration values to the appropriate components using the component framework. However, there might also be other reasons to prefer the approach you describe in the doc below. Regardless of whether you decide to use configuration capabilities, we should consider the option and explain the tradeoffs in the RFC.

Adam

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "eng-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eng-council...@fuchsia.dev.
To view this discussion visit https://groups.google.com/a/fuchsia.dev/d/msgid/eng-council/CAMsdVDNxxZEoJcbsqE1DLmFgsiSs%3DAECBYqLyamnUzj7LZsoAA%40mail.gmail.com.

[Adam Barth]

On Mon, Dec 8, 2025 at 11:59 AM Martin Lindsay <mlin...@google.com> wrote:

Yes an RFC makes sense, just wanted to start with general feedback.

The main reason for this flag system is that the flag values are not determined at build time, but are rather updated by the product which is receiving flag updates over the network. This is to support plumbing the flag systems that both Android and Cast use for their own remote flag control.

Yes, using configuration capabilities would require adding support for dynamically changing configuration values.

Adam

[Adam Barth]

Yes, I imagine that might end up being similar to the protocol in Martin's doc for notifying a component about changes to flag values.

Consider:

 (1) the similarities between the FlagValue struct in go/fuchsia-product-flags and fuchsia.component.runtime/Data, and

 (2) the analog between the FlagUpdate struct and the keys and values stored in a fuchsia.component.runtime/Dictionary.

It seems like the component framework has very similar building blocks that we could use to support this use case and gain all the other benefits of using component framework machinery (e.g., routing).

We can brainstorm in another forum if you would prefer, but maybe something like a DictionaryObserver would give us a way to notify components when this data changes. In this approach, the information wouldn't need to be provisioned to the component using the structured configuration bundle. We could just route each component a dictionary with the appropriate contents.

Adam

On Tue, Dec 9, 2025 at 6:43 AM Claire Gonyeo <cgo...@google.com> wrote:

I can imagine a way to plug a couple of current component framework features together that would let you dynamically update the value of config capabilities, but I think we'll have an issue (without new CF features) when it comes to this requirement from Martin's document:

> The sender must be able to signal to the receiver that a value has changed, even if the receiver chooses not to act on it immediately

When a component starts, component manager gathers together all of its configuration and delivers that as a single binary bundle on startup, which doesn't provide us a mechanism to tell the component about updates. Unless it's acceptable to tell a component about config capability updates by restarting the component, we'd need to build out a way to to pass along those updates.

[Claire Gonyeo]

I can imagine a way to plug a couple of current component framework features together that would let you dynamically update the value of config capabilities, but I think we'll have an issue (without new CF features) when it comes to this requirement from Martin's document:

> The sender must be able to signal to the receiver that a value has changed, even if the receiver chooses not to act on it immediately

When a component starts, component manager gathers together all of its configuration and delivers that as a single binary bundle on startup, which doesn't provide us a mechanism to tell the component about updates. Unless it's acceptable to tell a component about config capability updates by restarting the component, we'd need to build out a way to to pass along those updates.

On Mon, Dec 8, 2025 at 10:51 PM Adam Barth <aba...@google.com> wrote:

[Martin Lindsay]

Yes an RFC makes sense, just wanted to start with general feedback.

The main reason for this flag system is that the flag values are not determined at build time, but are rather updated by the product which is receiving flag updates over the network. This is to support plumbing the flag systems that both Android and Cast use for their own remote flag control.

On Mon, 8 Dec 2025 at 14:00, Adam Barth <aba...@google.com> wrote:

[Claire Gonyeo]

A DictionaryObserver (to mirror fuchsia.io.DirectoryWatcher) has been on my to-do list for a bit now, so I'm definitely supportive of that direction.

Martin: if you want to explore this alternative and want my help scoping out what would need to be added on the CF side, please reach out :)