[nimbus] Deprecating isEarlyStartup features and removal of NimbusFeatures C++ APIs

[Barret Rennie]

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.

Thanks for your cooperation,

Barret Rennie

[Nick Alexander]

Barret,

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

[Barret Rennie]

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