[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #17000 [metrics-lib]: Allow to distinguish between relay and bridge descriptors

#17000: Allow to distinguish between relay and bridge descriptors
-----------------------------+--------------------------
     Reporter:  karsten      |      Owner:  karsten
         Type:  enhancement  |     Status:  needs_review
     Priority:  normal       |  Milestone:
    Component:  metrics-lib  |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------

Comment (by karsten):

 Thanks for the reviews, atagar and iwakeh!

 I do agree that we could do better with respect to avoiding unnecessary
 code duplication.  But I'd rather want to do that for all descriptors and
 not just server and extra-info descriptors.  I'd say let's approach that
 once we know how to proceed with server and extra-info descriptors here.

 Regarding adding new types like `RelayServerDescriptor` or just adding
 methods like `isRelay()`, I slightly lean towards the former:

 What I usually do when using parsed descriptors is perform a check like
 `if (descriptor instanceof RelayServerDescriptor)`, which would be more
 complicated using these new methods:

 {{{
 if (descriptor instanceof ServerDescriptor) {
   ServerDescriptor serverDescriptor = (ServerDescriptor) descriptor;
   if (serverDescriptor.isRelay()) {
     // ...
   }
 }
 }}}

 Another reason is that new types allow us to add methods to either type in
 the future, even though we don't do that yet.  That's similar to Stem's
 model.

 So, what do you think about adding these new interfaces to the API?

 By the way, related to this discussion we might want to reconsider how
 `@type network-status-microdesc-consensus-3` are handled similar to `@type
 network-status-consensus-3`.  Maybe the former deserve their own
 interface, `RelayNetworkStatusMicrodescConsensus`.  That would be a new
 ticket though.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17000#comment:4>
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