Hey Nick,
Yeah I could see replacing the current implementation of
`NimbusFeature::Get{Bool,Int,String}` with a version that uses the pref
specified by `setPref`. I think that would be a good compromise.
With regards to `fallbckPref`, I haven't sent out the announcement yet, but
`fallbackPref` is going to be deprecated and replaced with a `default` key
that specifies the default value inline. This will bring Desktop's feature
manifest closer in line with the FML language used by mobile, with a future
goal of eventually unifying the two so we can share tooling (and
potentially implementation) across all Nimbus consuming applications.
With regards to testing, there is also a plan to start developing a Nimbus
DevTools extension that would allow on-the-fly configuration of experiments
and variable values.
--Barret
On Fri, Jan 19, 2024 at 12:31 PM Nick Alexander <[email protected]>
wrote:
> Barret,
>
> On Thu, Jan 18, 2024 at 11:58 AM Barret Rennie <[email protected]> wrote:
>
>> Hi everyone!
>>
>> In H1 the Nimbus team is planning to deprecate isEarlyStartup features in
>> the feature manifest. The plan is to migrate every feature that uses
>> isEarlyStartup to use setPref for any variables that need to be read before
>> the Nimbus store is ready.
>>
>> This will also result in the majority of the NimbusFeatures C++ APIs
>> being removed. There are very few consumers of this API to migrate and all
>> uses can be replaced with pref reads of setPref variables.
>>
>> This work will be tracked in bug 1875331
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1875331>.
>>
>
> Two small thoughts about this. First, `setPref` and `fallbackPref` are
> mutually exclusive at this time. We lose a little bit of local development
> and testing flexibility by not having `isEarlyStartup` and `fallbackPref`
> together. But the current Nimbus preference situation is so complicated
> and so frequently misconfigured that clean-up and focused normalization of
> this area is surely a good thing.
>
> Second, has there been a discussion of direct preference access vs. some
> Nimbus C++ API for reading that knows about `setPref`? It would be really
> nice to keep the Nimbus-level separate from the extremely general and hard
> to interrogate Gecko preferences system. That is, we lose implementation
> flexibility by exposing the underlying storage layer to consumers. What do
> we gain in return?
>
> Best,
> Nick
>
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CA%2BSxwbcnXSfvhfmrWDEGV-HgqsKNaB5V923Qdwpu99dwFgapWA%40mail.gmail.com.
