Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #12505

Closed (moved)
Open
Opened Jul 01, 2014 by Isis Lovecruft@isis

Refactor BridgeDB's hashrings

I have slowly been refactoring all of BridgeDB. Code which has been already refactored is named with "proper" (according to PEP8) lower-cased module names in lib/bridgedb in the BridgeDB repository.

Some of the largest, least-unitested, (and most difficult to refactor) sections of BridgeDB's code are the Bridges.py module and the Dist.py module. This code primarily controls the hashrings and the distributors (which for some reason are subclasses of the very-confused hashrings structures).

The biggest problems are:

  1. The code for the various types of hashrings in bridgedb.Bridges is a complete mess. In some places, hashrings are referred to as BridgeHolders, in other places as Buckets (though not to be confused with the Bucket.py module, and in other places as "hashrings". Subclassing is haphazard and confusing to say the least. In addition, the hashrings are not algorithmically as efficient as they could be. Throughout the hashring code were old-style classes, unused methods, half-implemented methods, and unnecessary parameters. All of this code needs some serious help.

  2. The Distributors in bridgedb.Dist inherit, for some unknown reason, from the improperly implemented "base class" bridgedb.Bridges.BridgeHolder. One, this isn't how one implements a proper Python base class (by deriving from a class with __metaclass__ = abc.ABCMeta). Two, why a Distributor should be a subclass of a the "base" hashring class is unclear and unnecessary, and we should move away from that. A Distributor is something which distributes bridges to users, not some weird half-thought-out hashring subclass.

  3. The various Distributors in bridgedb.Dist should be different modules.

  4. Almost none of the code in Bridges.py and Dist.py is unittested. These modules have the highest number of untested lines of code currently in BridgeDB.

After this is finished, I am mostly willing to tag BridgeDB-1.0.0. There may be a few other refactoring that should get finished before then, but this is the main piece remaining to be completed.

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#12505