Implement the basics of a bootstrap-status API.
The purpose of this API is to tell the user how far along Arti is in getting bootstrapped, and if it's stuck, what it's stuck on.
This API doesn't yet expose any useful information: by the time it's observable to a client, it's always "100% bootstrapped." But I'm putting it in a MR now so that we can review the basic idea, and to avoid conflicts with later work on tickets like #293 (closed) and #278 (closed).
This is part of #96 (closed).
Merge request reports
Activity
assigned to @nickm
Setting @eta as reviewer, but I wouldn't mind review from @Diziet as well. (As noted above, this MR is just for getting the key parts of the API in place, so I can fill in the implementation without stepping on @eta's feet wrt #278 (closed).)
requested review from @eta
- crates/arti-client/src/status.rs 0 → 100644
11 // 12 // We need to this type fairly small, since it will get cloned whenever it's 13 // observed on a stream. 14 #[derive(Debug, Clone, Default)] 15 pub struct BootstrapStatus { 16 /// A placeholder field: we'll be replacing this as the branch gets support 17 /// for more information sources. 18 ready: bool, 19 } 20 21 impl BootstrapStatus { 22 /// Return a rough fraction (from 0.0 to 1.0) representing how far along 23 /// the client's bootstrapping efforts are. 24 /// 25 /// 0 is defined as "just started"; 1 is defined as "ready to use." 26 pub fn as_frac(&self) -> f32 { -
It's based on the "x% bootstrapped" indicators that Tor gives out; it's meant for the cases where you absolutely want to shove it in a progress bar.
We could look at an ordering on status levels at some point, but that can actually be hard. For subtle reasons, there is not a total ordering on "how bootstrapped is this client." (eg, client 1 has a complete valid cached directory, but is offline. Client 2 is online, but has no directory information. Is one of them really "more botstrapped" than the other? From the POV of a progress bar, perhaps, but otherwise it's not so clear.)
I think maybe we also want to provide an
OperationalStatusLevelenum which isOrdand non exhaustive.Potentially, but I think I'd like to get an idea of what people would actually use that for first; if people are just going to compare the levels against one another, they might as well use this API.
On the other hand, if there are clients that actually want to change their UI / show specific actions at various points, then this'd make a lot of sense.
marked this merge request as draft from nickm/arti@e6762fb0
added 1 commit
- 9b16b02a - fixup! Implement the basics of a bootstrap-status API.