Opened 21 months ago
Last modified 14 months ago
#22512 new enhancement
Add enums for keywords used in exit lists, Torperf measurement results, bridge pool assignments, and soon sanitized web logs
Reported by: | karsten | Owned by: | metrics-team |
---|---|---|---|
Priority: | Medium | Milestone: | |
Component: | Metrics/Library | Version: | |
Severity: | Normal | Keywords: | metrics-2018 |
Cc: | Actual Points: | ||
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description (last modified by )
Todo derived from the discussion in comments 1 to 4:
Add keywords for all descriptors to Key
enum.
Use a one letter prefix for keywords from non-Tor data sources.
First step: determine the best letter for each non-Tor source.
Original summary: We recently introduced the Key
enum with keywords contained in relay descriptors, sanitized bridge descriptors, and sanitized bridge pool assignments. We did not include keywords in exit lists and Torperf measurement results, and in retrospect we should have excluded sanitized bridge pool assignments there.
The reason why each data source should have its own enum is that naming conventions might vary in terms of upper/lower case and word separators. For example, Tor descriptors use lower-case-keywords
, exit lists contain CamelCase
, and Torperf/OnionPerf use ALL_UPPER_CASE_WITH_UNDERSCORES
. There could be conflicts for keywords like source
vs. SOURCE
.
Child Tickets
Change History (8)
comment:1 Changed 21 months ago by
comment:2 Changed 21 months ago by
Ah, good point. How about we add a single-letter source prefix as in T_NETWORK_STATUS_VERSION("network-status-version")
where T_
would stand for "Tor descriptor"?
comment:3 Changed 21 months ago by
Single letter is fine.
As most Tor keywords are defined already and I assume there are more Tor related ones than non-Tor, I'd prefix non-Tor descriptors. This would also accommodate non-Tor keywords from different data sources that overlap. This is a different prefix for each non-Tor source.
comment:4 Changed 21 months ago by
Works for me. In any case, prefixing Tor keywords can be done really easily, and it only affects the implementation, not the interface. If we ever decide to also prefix Tor keywords, we can just do it.
comment:5 Changed 21 months ago by
Description: | modified (diff) |
---|
True! I added the new todos to the summary for easier reference.
comment:6 Changed 17 months ago by
Keywords: | metrics-2018 added |
---|
comment:7 Changed 17 months ago by
Keywords: | metrics-2017 added; metrics-2018 removed |
---|
comment:8 Changed 14 months ago by
Keywords: | metrics-2018 added; metrics-2017 removed |
---|
Will be completed in 2018.
Right, all descriptor parsing should make use of the
Key
keywords.Some things to consider:
There is no inheritance between enums. So, the ease of use in all descriptor parsing code would be lost with different Key-enums. When using only the general
Enum<T>
the.keyword
and other features ofKey
are lost.This yields toward the "adding more Key enums approach" instead of separate Enums.
There are no naming conventions yet (only implicitly). The possible naming problems suppose certain rules which were not introduced directly.
A working set of naming convention rules could be started with the aim of only using one
Key
enum. If there are similarKey
names as in the example above using 'source' a prefix could be added. It should be ok to not have a strict translation rule from the actual keyword to the enum name; only keep it heuristically close.