In theory we want the Rust API for events to be as safe and simple to use as possible.
That means we want it to be strictly typed over the extra keys a certain event can take,
disallowing to mix foreign extra keys into an event and statically preventing that.
The metric types as implemented in Rust for FOG are serving two purposes:
- A nice Rust API for Rust consumers.
The nice event metric API with static checks requires a generic type:
K holds the allowed extra keys, generated by
glean_parser at build time.
Now in FOG each metric is identified by its
metric id, by which it can be looked up in a map.
That map can hold only a single type of a metric.
If we have
n different event metrics with
n different sets of extra keys we can't store them in a single map.
We also can't have a map per event (that would easily become a lot of maps and also we don't have the generic type on the C++ side)
We can resolve this by weakening the API a bit:
We make an
EventMetric only generic over whether it has no extra keys or some extra keys.
This allows us to separate these events in 2 categories, requiring only 2 maps.
This further allows us to implement functionatility for either group specifically.
Events with no extra keys don't take anything on
Nothing needs to be serialized and it requires no runtime checks that extra values are allowed. There are none.
Events with some extra keys require a bit more work.
- For Rust consumers we can introduce a runtime type check to ensure the right extra keys are passed.
With the generated code we guide people to do the right thing.
For misuse that works around generated code we still have some checks
(by only mapping valid extra keys to their serialized variant).
What does this mean for the eventual RLB types?
They will need to use the same strategy, otherwise we can't wrap them in FOG.
That's a severe limitation of the API for Rust consumers outside of Firefox,
but I don't see any other way to make it work right now.
Note: a first implementation of the C++ side of things will follow in a