Opened 4 years ago
Last modified 23 months ago
#17861 assigned enhancement
Consider adding a new interface RelayNetworkStatusMicrodescConsensus
Reported by: | karsten | Owned by: | metrics-team |
---|---|---|---|
Priority: | Low | Milestone: | |
Component: | Metrics/Library | Version: | |
Severity: | Normal | Keywords: | metrics-2018 |
Cc: | Actual Points: | ||
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
There are currently three different version 3 network status document types, identified by the following @type
annotations:
@type network-status-vote-3 1.0
: these are votes exchanged by directory authorities;@type network-status-consensus-3 1.0
: these are (unflavored) consensuses based on votes and published by directory authorities;@type network-status-microdesc-consensus-3 1.0
: these are the same consensuses as before but using a specific flavor, in this case one that references microdescriptors rather than server descriptors.
So, while we're using a separate interface for the first type (RelayNetworkStatusVote
), we're using the same interface (RelayNetworkStatusConsensus
) for the second and third type. This only works, because the only differences between unflavored and microdesc-flavored consensuses can be found in the network status entries, and we're using the generic NetworkStatusEntry
for those. But as soon as there will be new keywords in either unflavored or microdesc-flavored consensuses, we'll have to add support for them to RelayNetworkStatusConsensus
, even though the other flavor doesn't support them.
We might consider adding another interface RelayNetworkStatusMicrodescConsensus
for microdesc-flavored consensus, which would probably just extend RelayNetworkStatusConsensus
for now (or copy over everything from it? uhhh). But if microdesc-flavored consensuses ever derive from unflavored consensus in header or footer, we'll be able to model those changes correctly.
Related to this suggestion, we might consider making NetworkStatusEntry
less generic by using a separate Entry
interface like we just did for ExitList
. Following that model, RelayNetworkStatusVote.Entry
would keep its getMicrodescriptorDigests()
method, RelayNetworkStatusConsensus.Entry
would drop that method, and RelayNetworkStatusMicrodescConsensus.Entry
would get a getMicrodescriptorDigest()
(singular) method.
I don't think these changes are super urgent, but I wanted to write them down before resolving #17000 where they first came up.
Child Tickets
Change History (7)
comment:1 Changed 3 years ago by
Milestone: | → metrics-lib 2.0.0 |
---|
comment:2 Changed 3 years ago by
Milestone: | metrics-lib 2.0.0 → metrics-lib 1.9.0 |
---|
comment:3 Changed 2 years ago by
Owner: | changed from karsten to iwakeh |
---|---|
Status: | new → accepted |
Taking this on together with #19640.
comment:4 Changed 2 years ago by
Milestone: | metrics-lib 1.9.0 |
---|
We decided today not to let this ticket (and #19640) delay the 1.9.0 release, and 2.0.0 won't be a good target milestone either. Taking this out of planned milestones for now.
comment:5 Changed 2 years ago by
Keywords: | metrics-2018 added |
---|
comment:7 Changed 23 months ago by
Owner: | changed from iwakeh to metrics-team |
---|---|
Status: | accepted → assigned |
Move to metrics-team as these are not worked on by me during the next week.
This should be considered when working on #19640.