[tbb-dev] Tor Button Proposal

[Mark Smith]

On 1/15/18 1:13 PM, Arthur D. Edelstein wrote:
> 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.

More accurately, this step *avoids* WebExtensions entirely and all of
the issues associated with a move in that direction. Kathy and I agree
with this approach; it seems more productive to work on Tor Browser
things than to work on transitioning extensions to WebExtensions to add
the features that what we need. Matt's proposal to use a hybrid approach
is also a possibility, but it seems better to stick with XUL/XPCOM for now.

> * 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.

Trying to keep things working on both desktop and mobile may slow down
the mobile work a little, but it is important if we want to achieve the
goal of a common codebase. This stage will also force us to cleanup the
existing code. :) Those of us who have worked on Torbutton and Tor
Launcher for the desktop may need to help with some of this; at the very
least, we can review the refactoring work and help check for regressions.

> * 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.

Over time, we can also consider moving some front-end pieces to
WebExtensions or XHTML. As Mozilla moves away from XUL/XPCOM for their
frontend code, we should do the same. In other words, we should try to
follow their lead unless we have a good reason not to do so.

-Mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20180116/37c9f8e6/attachment.sig>