Skip to content
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

probeservices: cleanup and refactoring to prepare for richer input #2362

Closed
4 of 9 tasks
bassosimone opened this issue Nov 22, 2022 · 1 comment
Closed
4 of 9 tasks
Assignees

Comments

@bassosimone
Copy link
Contributor

bassosimone commented Nov 22, 2022

To do ooni/ooni.org#1292, we first need to do a pass of cleanup and refactoring of the probeservices package, which is where we will need to implement the change. Here are some of the activities we should perform:

Once these cleanups have been implemented, we will have simplified the implementation that needs to be modified to deal with richer input (hence reducing the impact of the change) thus creating the optimal conditions for introducing a richer input.

@bassosimone bassosimone self-assigned this Nov 22, 2022
bassosimone added a commit to ooni/probe-cli that referenced this issue Dec 14, 2022
The underlying rationale is that I want to annotate a Descriptor
with the request and response type, using generics.

Such a change will allow me to automatically generate a swagger
to compare to the one used by the OONI API.

Reference issue: ooni/probe#2362
bassosimone added a commit to ooni/probe-cli that referenced this issue Dec 14, 2022
The underlying rationale is that I want to annotate a Descriptor
with the request and response type, using generics.

Such a change will allow me to automatically generate a swagger
to compare to the one used by the OONI API.

Reference issue: ooni/probe#2362

While there, zap an integration test that I missed in
#1006
@bassosimone
Copy link
Contributor Author

The scope of this issue is probably too broad. I think it is better to spec out a more narrow issue, such as #2597, which defines a very clear goal, and then eventually fork off child issues if it seems #2597 is too broad. Roughly speaking, these two issues call for the ~same changes, but I'd rather to use #2597 instead because it is dependent on a concrete improvement, while this one is too broad. (This issue was originally an Epic, which is why was too broad, but we're trying to work on smaller issues and less Epics now, which is why I'd like to replace this issue with a more narrow one and I do not feel super happy about rewriting the content of this issue entirely when a new issue would be more clear.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants