9cc8b2dba7This pull request introduces two big changes:
* The implementation of the new HTTP API for the `l10n` module. Bear in
mind that the specification is still a work in progress.
* The new architecture for Agama services. The `l10n` module has been
heavily reorganized to:
* support the new API.
* make it easier to maintain in the future.
## The new HTTP API
Here is a brief explanation of how the new API should look like. For
further details, check [the ongoing
description](https://gist.github.com/joseivanlopez/ed9f4f87b214ff60d52a5f6c3897dc9d).
In general, it is designed around 3 main concepts:
* system: represents the current status of the running system. It is not
only about the configuration, but it can offer additional information
(e.g., the list of supported languages, products, hardware information,
etc.).
* config: represents the user configuration for the target system.
* proposal: represents what is going to happen during installation.
Here is the API summary (check whether we have done some changes):
~~~
GET /system
GET /extended_config
GET /extended_config/{scope}
GET PUT PATCH /config
GET PUT PATCH /config/{scope}
GET POST PATCH /questions
GET /proposal
GET /state
GET /issues
POST /action
~~~
This new design allows us to drastically reduce the complexity and the
amount of code needed by the old API.
Of course, we still need to extend it to support more use cases
(software, DASD, progress, etc.) but this one is a step in the direction
we want to take.
## The new architecture
Coming from a set of separate single-thread D-Bus services, we had have
time to identify a few limitations that we would like to overcome in
this redesign. Given that we expect several process to collaborate
(holding configuration, listening for system changes, etc.) we want to
implement something similar to an *very simplified* [actor
model](https://en.wikipedia.org/wiki/Actor_model).
With this idea in mind, each Agama module (localization, software, etc.)
will live in their own package (e.g., `agama-l10n`, `agama-software`,
etc.) implementing the corresponding actors/services. `agama-utils`
contains a `module` with some utilities to implement this pattern.
<img width="1280" height="720" alt="agama-new-architecture"
src="https://github.com/user-attachments/assets/664c3954-8b8f-4b1c-82c8-d0972f1ba3cd"
/>
## Actors implementation
We started using the enum-based approach described in [Actors in
Tokio](https://www.reddit.com/r/rust/comments/100s26c/actors_with_tokio_a_lesson_in_ownership_rustlab/)
(really great). However, after some discussion, we decided to go with a
trait-based approach. See [the actors module for further
information](8d2f028813/rust/agama-utils/src/actors.rs).
---------
Co-authored-by: Knut Anderssen <kanderssen@suse.com>
Co-authored-by: José Iván López González <jlopez@suse.com>
Co-authored-by: David Díaz González <dgonzalez@suse.com>
77 B
77 B
- [] Move server error to the supervisor.
- [] Add test to the config merge.