1663597 - Investigate moving pre-initialization “caching” of values to glean-core

Status: RESOLVED INCOMPLETE

(Data Platform and Tools :: Glean: SDK, enhancement, P3)

Description

[Beatriz Rizental [:brizental]]

From Investigation: what logic can we move from the bindings to the core?:

Each one of Glean’s language bindings exposes a global Glean object for our users to interact with. One of the functions exposed by this object is initialize, used to actually initialize the Glean singleton on the Rust core and, after that, perform other initialization tasks. This should be called by our users ASAP, but since it is asynchronous we need to be aware that users may call other functions on the Glean object, before the Glean singleton is initialized.

To deal with that, we currently have a “caching” mechanism. If a user calls a certain function before Glean is initialized, we “cache” the argument used and replay that function on the Glean singleton once it is initialized.

One example of such a pattern is the setDebugViewTag function. If this function is called before initialize is done, we save the given tag on a temporary place. Once the Glean singleton is actually initialized, we replay that function call with the saved argument.

My proposed way in dealing with this issue, is to refactor Glean’s initialization logic to use a Builder-style pattern. This would allow us to initialize the Builder struct before initialize is called on the binding side, and in case the Glean singleton doesn’t exist yet, we can call functions on the Builder, allowing the “caching” to be done on the Rust side.

Doing such a refactoring work would have more benefits than just allowing us to remove the “caching” logic from the bindings. It would also allow us to get rid of the Configuration object, which has its own benefits such as lowering the amount of boilerplate when adding a new config option to Glean and making it easier to define defaults to Glean’s config options."

Implementation details

The Builder object would have to live in a OnceCell, just like the actual Glean object. When done building the Builder can then be dropped leaving only the Glean singleton.

A prototype of this can be found at: https://github.com/mozilla/glean/compare/main...brizental:1651382-builder-poc

Comment 1

[Jan-Erik Rediger [:janerik]]

Would need to be rethought after UniFFI. I don't think there's the same benefit anymore, now that UniFFI will take care of most of the binding overhead.