[tor-bugs] #12029 [BridgeDB]: Redesign BridgeDB's class inheritance to make designing new distributors easier

[Tor Bug Tracker & Wiki]

#12029: Redesign BridgeDB's class inheritance to make designing new distributors
easier
-------------------------------------------+----------------------
 Reporter:  isis                           |          Owner:  isis
     Type:  defect                         |         Status:  new
 Priority:  major                          |      Milestone:
Component:  BridgeDB                       |        Version:
 Keywords:  bridgedb-dist, bridgedb-0.2.x  |  Actual Points:
Parent ID:                                 |         Points:
-------------------------------------------+----------------------
 Everything is piled in `lib/bridgedb/Dist.py` right now, with a lack of
 organisation and documentation, making it rather overwhelming for others
 to design new distributors.

 Here are some of the things which should be revised:

  1. '''Distributor Class Interface''' The class inheritance design of
 current distributors is all within one file and doesn't have any clear
 indication of what methods/attributes are necessary to create a new
 distributor. There should probably be a `zope.interface.Interface` class
 so that implementations of new distributors can be easily checked to see
 that they meet the specification.

  2. '''Distributor Class Inheritance''' The current `Distributor` "base
 class" in `lib/bridgedb/Dist.py` inherits from
 `bridgedb.Bridges.BridgeHolder` which is one of the hashring classes. I've
 never looked into why this is done, but these should likely be distinct
 and separate classes. Either way the code in `lib/bridgedb/Bridges.py` is
 a complete mess as well, and will likely need some cleanup.

  3. '''Hide Database Transactions''' There should probably be some sort of
 `getBridgesFromDBManager()` method for distributors, so that they can send
 a `bridgedb.bridgerequest.BridgeRequest` (or subclass) to a database
 manager.
     - This method should expect to interact with a system, called the
 `DatabaseManager`, that doesn't exist yet because I'm currently building
 it, and also expect to receive some JSON in return which contains
 appropriate bridges for the client's request.
     - This is so that the `DatabaseManager` can handle `BridgeRequest`
 queuing and database transactions, and the distributor can continue going
 about its business without having to worry about interacting with
 hashrings or databases or any of the complicated backend stuff.
     - This should permit the distributors to be run in separate processes
 (or on separate systems), so that they can interact with the
 `DatabaseManager` remotely, which will help later when/if we wish to run
 future distributors with a larger potential attack surface (such as an
 OTR/XMPP distributor).

 There might be more things which will be necessary to change which will be
 discovered either while hacking on the revision, or while a new
 distributor is being created through subclassing and working with the new
 API; these things should be added to this ticket (or a new ticket, then
 mentioned here).

 We might want some sort of `DistributorTests` mixin class for creating
 `twisted.trial.unittest.TestCase`s from, so that they have some default
 checks.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12029>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online