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

Re: [tor-bugs] #6417 [Stem]: Controller wrapper method for USEFEATURE messages



#6417: Controller wrapper method for USEFEATURE messages
--------------------+-------------------------------------------------------
 Reporter:  neena   |          Owner:  neena         
     Type:  defect  |         Status:  needs_revision
 Priority:  normal  |      Milestone:                
Component:  Stem    |        Version:                
 Keywords:          |         Parent:                
   Points:          |   Actualpoints:                
--------------------+-------------------------------------------------------
Changes (by atagar):

  * status:  needs_review => needs_revision


Comment:

 Looks great.

 > +    The following features are currently accepted:
 > +      * EXTENDED_EVENTS - Requests the extended event syntax. Has the
 same
 > +          effect as calling SETEVENTS with EXTENDED. Introduced in
 > +          0.1.2.3-alpha, always-on since Tor 0.2.2.1-alpha
 > +      * VERBOSE_NAMES - Replaces ServerID with LongName in events and
 GETINFO
 > +          results. LongName provides a Fingerprint for all routers, an
 indication
 > +          of Named status, and a Nickname if one is known. LongName is
 strictly
 > +          more informative than ServerID, which only provides either a
 Fingerprint
 > +          or a Nickname. Introduced in 0.1.2.2-alpha, always-on since
 Tor
 > +          0.2.2.1-alpha.

 Lets not copy the control-spec. I agree that it's nice to have this in our
 documentation, but if we do this then we get into the business of
 mirroring this section (or getting stale). Maybe just list the options
 with a short summary and mention that users can read the control-spec for
 details?

 Usually I'd ask for these requirements to be added to version.py (and
 spotted that you did for FEATURE_VERBOSENAMES), but 0.1.2.2 and 0.1.2.3
 are so incredibly ancient that my humble opinion is that this note should
 be removed from the control-spec instead. The 0.2.2.1 always-on part might
 be interesting though. Is there a method to query if a given feature is
 enabled? If not then we could use this to add one...

 {{{
 def is_feature_enabled(self, feature):
   defaulted_version = None

   if feature == "EXTENDED_EVENTS":
     defaulted_version = stem.version.Requirement.EXTENDED_EVENTS_DEFAULTED
   elif feature == "VERBOSE_NAMES":
     defaulted_version = stem.version.Requirement.VERBOSE_NAMES_DEFAULTED

   if defaulted_version and
 default_version.meets_requirements(self.get_version()):
     return True
   else:
     return feature in self.enabled_features
 }}}

 Thoughts?

 > +      if test.runner.require_version(self,
 stem.version.Requirement.FEATURE_VERBOSENAMES):
 > +        controller.enable_feature("VERBOSE_NAMES")

 Can we do something that requires VERBOSE_NAMES so we can confirm that it
 is now on?

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