Slimming Clank working group meeting notes 11/2

[Alexandre]

We're spinning up a new working group to clean up the cruft in the Android-specific (Clank and WebView) code in content/browser/, ui/, and (with lower priority for now) chrome/.  I'm calling it "Slimming Clank" because we want net negative lines of substantive code and to greatly reduce the mental complexity of the system.  (Some of the subprojects also will speed up Clank and improve memory usage, as a secondary objective.)

We had our first biweekly meeting this afternoon (4PM PT).

This is a our kickoff meeting so we talked about overall goals and direction:

A) "Delete ContentViewCore".  This is a synecdoche for the tangle of content/browser/ goals (which strictly speaking don't have to involve ContentViewCore per se):

• Enforce the content/public boundary.  content/ objects holding a chrome/ object reference (and vice versa) must access it in terms of an interface class defined in content/public.  There shouldn't be much/any substantive code in content/public.
  
• Establish proper lifetimes.  Resource/state naturally lives where it belongs so that it's implicitly freed with no extra code.
  
• Separate the geometry ("View/Window") tree and geometry-less ("WebContents") tree
  

B) chrome/-related projects.  These are quite separate from (A) so potentially we can put them on a separate track in parallel/isolation:

• Make the Tab model structured the same as other platforms.
  
• Simplify the thumbnail/screenshot system to fix its all its racy, circumstantial bugs.
  
• Stop using the Layer Compositor (cc::Layer).  Switch to using the Display Compositor (cc::DrawQuad) directly instead.  (Some implications here for content/ but most of the work will be in chrome/.)
  

Other topics discussed:

Is unifying with other platforms a goal?  Sort of -- we intend to get it as a side benefit of things that are also worth doing for their own sake.

• We don't want to unify with Aura because we found out from attempting Andromeda project that Aura itself has massive cruft and would itself need a lot of refactoring for Clank to start using it.  Aura is on track to be replaced with Mus and eventually we want Clank to adopt Mus, but that's not ready yet.
  
• We should make our structure match the other platforms (where the other platforms have a superior structure to us, but not necessarily where they don't)
  
• Deleting code and complexity means that it will be less work to unify because there will be less impossible-to-understand cruft that we need to figure out how to share between platforms.  Boiling down our platform-specific needs to their essence is a prerequisite for elegant unification anyway, even if the simplification is to a different implementation/code structure.
  

How to allocate tasks?

• (A) needs to be attacked leaf node first in this dependency graph, but there are many leaves, so it's parallelizable.  Projects in (B) are generally separate from (A) and from each other; when appropriate, we could fork the meatier ones out of this working group entirely.
  
• Breakdown of (A) tasks already in this doc.
  
• Future meetings should have more nitty-gritty on the task triage, status sync-up, and specific design debates.

[Jinsuk Kim]

Thanks for the summary Alex. One thing I noticed while refactoring is that LOC has a tendency to increase (though not significant) rather than decrease, mostly due to new boilerplate code for new classes and plumbing being added to replace what was being done in CVC. We should keep an eye on this to avoid unnecessary growth - but doing things properly may not necessarily mean doing it with fewer lines of code.

[Bo Liu]

Part of LOC increase is due to split between content vs content_public where there was no split before.

--
You received this message because you are subscribed to the Google Groups "Slimming Clank" group.
To unsubscribe from this group and stop receiving emails from it, send an email to slimming-clank+unsubscribe@chromium.org.
To post to this group, send email to slimmin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/slimming-clank/1a4d1bd2-5872-4dc5-b73d-16ec4e16c63e%40chromium.org.

[Alexandre Elias]

Yeah, I was trying to make that nuance with the word "substantive".  I want to delete code like if statements and class data member declarations.  But it's fine to add stuff like base class interfaces.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/slimming-clank/CAPCJOUoEn9RXq__crMDs0Y4-qUwHfi_9d9FBuEq5_ssJmzRJfQ%40mail.gmail.com.