Btw, both Ryan and Ben pointed out some theoretical prospect of supporting some interventions on ios (eg, AMP redirection).

My thoughts on the matter:

I personally think it would be a good idea to flatten previews and d_r_p since it seems like we don't want to support iOS at any point. Based on previews/ and d_r_p/ coupling, I wonder if we should either combine those components or split the previews code from d_r_p more intentionally. (see how client_lofi is used in DRPNetworkDelegate).

The way I see it there are a few components in this space that end up sharing some functionality:

Interventions -- changing a page load for the user benefit

Previews -- low fidelity interventions

Data Reduction Proxy -- A proxy that serves both Previews and high-fidelity interventions

Data Saver -- An option in the browser that triggers behavior related to previews, DRP, and interventions

Local Blacklist -- A mechanism that takes user history into account when deciding to serve a Preview or other intervention

Previews, DRP, the blacklist, and Data Saver all fall under interventions. It might be the case that we should refactor all of the code into components/interventions and reduce some overhead (e.g., we have 2 keyed services).

In terms of breaking these logically into pieces, we have:
a collection of net/ interfaces that could be shared
a collection of DRP objects that control the functionality of the proxy server
a collection of objects and interfaces related to the local blacklist
a collection of objects that track data savings
a triggering pathway that decides how these things interact

Outside of components (in chrome/browser/previews mostly) we have:
Previews Infobar objects
Chrome layers for DRP and previews (keyed services)
Other UI code

Things that will likely be added:
Page load capping classes in the previews component and chrome/browser/previews

This seems to be the logical breakdown to me:

src/components/interventions
--BlackList/Triggering code/What experiments are enabled
--Net/ delegates (which will communicate with other sub-directories here)
--DRP functionality code
--DataSavings stats tracking
--PageLoadCapping
--Other Previews code?

src/chrome/browser/interventions
--PreviewsInfobar
--DRP/Previews chrome/ code (might just be interventions)
--Page Load Capping infobar

This is a really lofty goal to get to that file structure, IMO, but it does help with other efforts like mojo-fication to get things more logical split.

+1 to flattening the components, despite a remotely possible future world with iOS previews.

I mostly agree with the thoughts in #2, but think that a re-architecture is an orthogonal issue. I think it will be hard to move to better place without describing what each component does at the API level. Let's move that discussion offline until we have some local consensus on what to do.

We might want to flatten previews in the near term to make a new optimization_guide component (for cacao data) less complicated than if we keep it layered.

I wonder about a modestly ambitious initial step of flattening components/previews and relocating components/data_reduction_proxy/core/browser (which has the previews/core dependency) to either d_r_p/browser or merge in with d_r_p/content/browser. Maybe we can discuss in today's team meeting.

Refreshed during triage.

Refreshed during triage.

Refreshed during triage.