Re: When to add flags to network status vs adding new items

[Mike Perry <mikepery@xxxxxxxxxx>]

Thus spake Roger Dingledine (arma@xxxxxxx):

> This is mainly for Nick, but maybe we'll get back into the habit of
> making design discussions more public. :)
> 
> I'm in the process of implementing PreferTunnelledDirConns, which makes
> you pick a directory server that supports BEGIN_DIR cells if one is
> available. But the routerstatus_t or local_routerstatus_t structs don't
> say what version the server is running, so I can't know. (And I can't
> just fetch all the descriptors to learn the versions, because the whole
> point is to fetch them using BEGIN_DIR when possible.)
> 
> One option is to add another flag to the status lines:
> supports_dir_tunnels or the like, which is set when we believe the server
> is running Tor 0.1.2.2-alpha or later.
> 
> Another option is to extend the router line in the status list to include
> the version we think it's running, and then clients can make this decision
> (and future decisions) themselves.
> 
> Both of these would be fine with me in this case. What's the right habit
> down the road? Should we add new flags whenever there's a new capability,
> or should we reserve flags for situations where the judgement is more
> complex than a call to tor_version_as_new_as()?

I can give a opinion from the controller's point of view.

Flags could get annoying, since the network status line for the
controller will become more ugly to parse.  Also, if a controller is
only interested in talking to tor servers of a certain version or
version range, it would be easier to decide this before fetching
the whole directory entry via a GETINFO.

The main argument against it probably would be if there are
non-freehaven tor server implementations out there that supported some
subset of the functionality which is best represented by flags and not
version.. but since there aren't any, and you're already checking versions
elsewhere anyways, probably is better just to go with the version?


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs