[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #17919 [Onionoo]: Document history objects better
#17919: Document history objects better
---------------------------+-----------------------------------
Reporter: seansaito | Owner: karsten
Type: task | Status: needs_information
Priority: Medium | Milestone:
Component: Onionoo | Version:
Severity: Normal | Resolution:
Keywords: documentation | Actual Points:
Parent ID: | Points:
Sponsor: |
---------------------------+-----------------------------------
Comment (by virgil):
> Keeping data on Roster itself is not a good option, as I stated before.
It should be stateless (except for caching) and rely on Onionoo to keep
all state it needs.
We are currently on course for Roster to have a state when it comes to
replacing Tor Weather (knowing which operators have redeemed their
shirts), but I hear you loud and clear. ÂWe (Sean and I) will go above and
beyond to minimize any kept state.
> What's your use case here?
We want the points to extend back in time (for simplicity, lets just say
100 days). ÂThe current badges are:Â`{bandwidth, exit bandwidth, consensus
weight}`(probably more later). Â So we'd like to be able to get each of
these per extended_family (ideally per relay, but we'll take what we can
get), calculated per day, for the past 100 days. ÂWorst comes to worst, we
''could'' just retain the relevant Onionoo data from the past 100 days.
We are not 100% opposed to this, but that's obviously a lot of state to
keep, and per above you want us to minimize state. ÂWhat's your suggested
path forward? ÂNo wrong answers.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17919#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs