-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: introduce richer input #1615
Conversation
f59d7fc
to
5846dfe
Compare
Most of the existing code is designed to move around lists of `model.OOAPIURLInfo` and measuring such URLs. This design originally suited Web Connectivity but it's not good enough for richer input because it does not contain options. With this diff, we move into the direction of richer input by replacing `model.OOAPIURLInfo` lists with lists of: ```Go // internal/model/experiment.go type ExperimentTarget struct { Category() string Country() string Input() string } ``` where `*model.OOAPIURLInfo` implements `model.ExperimentTarget` in a trivial way and where, additionally: 1. the `InputLoader` is modified to load `ExperimentTarget`; 2. the `Experiment` is modify to measure an `ExperimentTarget`. In addition to applying these changes, this diff also adapts the whole tree to use `ExperimentTarget` in all places and adds a trivial constructor to obtain `OOAPIURLInfo` when the category code and the country code are unknown. With this diff merged, implementing richer input for real is a matter of implementing the following changes: 1. the `*registry.Factory` has a new func field, defined by each experiment, that loads a list of `ExperimentTarget`; 2. we have a library for input loading containing the same code that we currently use for the input loader; 3. the `InputLoader` is gone and instead we use the factory (or its `*engine.experimentBuilder` wrapper for input loading; 4. we modify the `ExperimentArgs` passed to the `ExperimentMeasurer` to contain an additional field that is the `ExperimentTarget` we want to measure; 5. each experiment that needs richer input type-casts from the `ExperimentTarget` interface to the concrete type that the experiment richer input should have and accesses any option. Part of #1612. This implementation strategy emerged while discussing this matter with @ainghazal, thank you so much for that!
@@ -204,7 +207,7 @@ func (e *experiment) MeasureWithContext(ctx context.Context, input string) (*mod | |||
// by adding the test keys etc. Please, note that, as of 2024-06-05, we're using | |||
// the measurement Input to provide input to an experiment. We'll probably | |||
// change this, when we'll have finished implementing richer input. | |||
measurement := e.newMeasurement(input) | |||
measurement := e.newMeasurement(target.Input()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A follow-up diff will modify newMeasurement
to also read the options from the target
such that we can correctly field the top-level key named options
of the measurement.
for _, URL := range input { | ||
if _, err := url.Parse(URL); err != nil { | ||
return nil, err | ||
} | ||
output = append(output, model.OOAPIURLInfo{ | ||
CategoryCode: "MISC", // hard to find a category | ||
CountryCode: "XX", // representing no country |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, ZZ
represents no country. I don't know where I did take XX
from.
Is this something that check-in may possibly return?! (I am not sure here!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's what check-in would do: https://github.com/ooni/backend/blob/f7a93f477111c7278424996815b91e6300d66b83/api/ooniapi/prio.py#L182.
So, I guess we should revert back to using "ZZ", since it's what we'd get if check-in didn't know the country.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed by 5830436
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The diff looks good to me. I left a bikeshedding remark.
Co-authored-by: DecFox <[email protected]>
Conflicts: internal/engine/inputloader.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
This commit moves the engine.InputLoader type to a new package called inputloading and adapts the naming to avoid stuttering. The reason for moving InputLoader is that the engine package depends on registry, and, per the plan described by the first richer input PR, #1615, we want to move input loading directly inside the registry. To this end, we need to move the input loading feature outside of engine to avoid creating import loops. We keep an integration test inside the engine package because it seems such an integration test was checking both engine and the InputLoader together. We may further refactor this test in the future. Part of #1612
This commit moves the engine.InputLoader type to a new package called inputloading and adapts the naming to avoid stuttering. We therefore have engine.InputLoaderSession => targetloading.Session and other similar renames. The reason for moving InputLoader is that the engine package depends on registry, and, per the plan described by the first richer input PR, #1615, we want to move target loading directly inside the registry. To this end, we need to move the target loading feature outside of engine to avoid creating import loops, which prevent the code from compiling because Go does not support them. While there, name the package targetloading rather than inputloading since richer input is all about targets, where a target is defined by the (input, options) tuple. Also, try to consistently rename types to mention targets. We keep an integration test inside the engine package because it seems such an integration test was checking both engine and the Loader together. We may further refactor this test in the future. Part of #1612 --------- Co-authored-by: DecFox <[email protected]>
Most of the existing code is designed to move around lists of
model.OOAPIURLInfo
and measuring such URLs.The
model.OOAPIURLInfo
type is like:This design originally suited Web Connectivity but it's not good enough for richer input because it does not contain options.
With this diff, we move into the direction of richer input by replacing
model.OOAPIURLInfo
lists with lists of:where
*model.OOAPIURLInfo
implementsmodel.ExperimentTarget
in a trivial way and where, additionally:the
InputLoader
is modified to loadExperimentTarget
;the
Experiment
is modify to measure anExperimentTarget
.In addition to applying these changes, this diff also adapts the whole tree to use
ExperimentTarget
in all places and adds a trivial constructor to obtainOOAPIURLInfo
when the category code and the country code are unknown.With this diff merged, implementing richer input for real is a matter of implementing the following changes:
the
*registry.Factory
has a new func field, defined by each experiment, that loads a list ofExperimentTarget
;we have a library for input loading containing the same code that we currently use for the input loader;
the
InputLoader
is gone and instead we use the factory (or its*engine.experimentBuilder
wrapper) for input loading;we modify the
ExperimentArgs
passed to theExperimentMeasurer
to contain an additional field that is theExperimentTarget
we want to measure;each experiment that needs richer input type-casts from the
ExperimentTarget
interface to the concrete type that the experiment richer input should have and accesses any option.Part of #1612.
This implementation strategy emerged while discussing this matter with @ainghazal, thank you so much for that!