[tbb-dev] Tor Button Proposal

[Arthur D. Edelstein]

On Mon, Jan 15, 2018 at 8:21 AM, Igor Oliveira <igt0 at torproject.org> wrote:

> Yep, after the latest Monday meeting, the Arthur's idea of making
> progressive changes instead of refactoring everything at once make totally
> sense.

Hi everyone -- just to try to clarify that a little, here's a staged
approach I would like to propose. In addition to being a step-by-step
model, I see this approach as minimizing the risk of causing
regressions in the existing desktop implementation, and, for the sake
of efficiency, avoids re-implementing or forking code except where
necessary:

* Stage 1 (Move and Fix): We move tor-launcher and torbutton into
their own directories in tor-browser.git (similar to how pdfjs lives)
without making any code changes or changes to the file structure
except whatever is required to make them continue to work on desktop.
My guess/hope is that the changes will be relatively small, because
XUL and XPCOM still work internally in Firefox. This step solves the
WebExtensions problem and thus needs to happen for desktop anyway for
ESR60.

* Stage 2 (Extend to Android): The mobile team makes a series of
patches to torbutton and tor-launcher to get each feature working on
mobile, while making sure there aren't regressions on desktop. I
imagine this would require refactoring to separate out business logic
from UI, and then writing a separate UI part for mobile that talks to
the same business logic.

* Stage 3 (Maintain): Once the Android code is fully working, both
desktop and mobile teams continue to maintain and improve torbutton
and tor-launcher code. Improvements to business logic will benefit
both desktop and mobile. We can also continue to refactor, including
moving files out from under torbutton or tor-launcher directories into
other locations as needed. For example, as Georg suggests, we could
refactor controller code into a module that is used by both torbutton
and tor-launcher.

Discussion/disagreement welcome! :)