Open horahoradev opened 2 years ago
This issue has been assigned to Whiffmerchant. It seems that I can't assign issues to people without having invited them as collaborators, which would give them write access.
Just protect dev
and master
branches from pushes by anyone but you.
Also "tone" is a bit too vague, pretty sure type
is more fitting.
Context and Motivation
Recently, archival events were added to give the user greater visibility into the state of their archives. For now, these messages provide indications about when videos are scheduled for download, and then a message indicating whether they've succeeded or failed. That's fine, but it's ugly, and a poor approximation of the original design intention: https://raw.githubusercontent.com/horahoradev/horahora-designs/master/Archives_1.png
As a step forward, it would be nice to add a "Tone" field to each archival event, which would indicate the nature of the message. For example, if a video fails to download, that would be an "Error", and could be colored red on the frontend. If a video download succeeds, that would be a "Success", and would be colored green. Other messages which are purely informative could be set to "Info", and could be colored white.
Why do any of this on the server instead of the client? We want this to be extensible. What if we want to inform the user if their archived video has hit 100 views? It's subjective, but I think that would be a great future usage for the archival events feature.
Prerequisites
I'd recommend learning about the following topics before approaching this:
Implementation
This feature will need to touch three components:
Note: the following is an overview, and isn't provided in-order. See the "Ordering" section at the bottom for a suggested execution order.
Scheduler
We'll need to add a new field to the schema of archival_events, indicating the tone of the message. You could either use an int, or an enum, but an int would probably be more extensible. We can define constants within the application itself.
Next, we'll need to change scheduler's events API to add a tone argument: https://github.com/horahoradev/horahora/blob/master/scheduler/internal/models/video_dl_request.go#L63
(it's just one method)
Once that's done, we'll need to change all clients of this method to add a tone argument, e.g. Success, info, or Error. If it compiles, you've changed all client sites correctly.
Lastly, we'll need to change the response protobuf definition for scheduler's "listArchivalEntries" method, here: https://github.com/horahoradev/horahora/blob/master/scheduler/protocol/scheduler.proto#L30
We'll add a new field indicating the tone, regenerate the code, and add the tone to our GRPC response.
First, we'll need to change the fields we're querying for within scheduler: https://github.com/horahoradev/horahora/blob/master/scheduler/internal/models/archive_request_repo.go#L44
Add the new "tone" database field, and change the "Event" struct accordingly (e.g. add a new int64 field named "tone"), then add it to the invocation of scan, here: https://github.com/horahoradev/horahora/blob/master/scheduler/internal/models/archive_request_repo.go#L65
From there, you'll just need to add it to the GRPC response: https://github.com/horahoradev/horahora/blob/master/scheduler/internal/grpc/grpc.go#L86
Front_api
Front_api is the RESTful API that the frontend interacts with.
The route GET /archivalrequests returns both the current request list and any events: https://github.com/horahoradev/horahora/blob/master/front_api/routes/GET_archiverequests.go#L16
All you'll need to do here is change front_api's version of scheduler's protobuf definitions to match the latest version. For some reason, I return scheduler's generated protobuf types directly here as JSON (maybe this should change, but it doesn't particularly matter).
Webapp
Once the above is done, you should be able to login, visit /archivalevents and see the "Tone" field you've added in each event. From here, we'd want to add a new field in the events table indicating the nature of the event. If it's a success, we should have a green checkmark, and if it's an error, we should have a red X (or something).
Ordering
Here's how I'd approach this:
sudo ./gen_protos.sh
(this is a script which will generate the definitions for GRPC)go get github.com/<your username>/horahora/scheduler@<latest commit>
within front_api to pin its proto definition to the latestsudo make up
, login, archive something, navigate to the archival requests page and see if the network tab shows that you're receiving the new tone fieldNotes
I will probably separate the API for getting archival events vs archival requests in the future, but I can still leverage any work that's been done here to add tone to events.