[tbb-dev] Tor Button Proposal

[Georg Koppen]

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.

I have not read the other proposal yet but +1 to this step 1 in general.
I think it is okay, though, to just remove dead code while moving.

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

Agreed. However, I think it is a good idea for those of us who touch big
parts of Torbutton and/or Tor Launcher code during the transition to
think about whether to rewrite the replacement with mobile needs in
mind. Depending on the task we could have the time to do so at that
particular moment and it would avoid spending extra work.

Things to consider that come currently to mind are #24309 and child
tickets and the reorganization of the toolbar/security controls.

Georg

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