Hello humans (not ghosts -- definitely not ghosts!), I hope you are all preparing your Hallowe'en costumes. We held a Mobile Tech Leads meeting on Wednesday (NA/AU timezones). As mentioned in last week’s summary email <https://lists.mozilla.org/pipermail/android-components/2018-September/000038.html>, there has been a very involved discussion about the architecture of Android Components, browser data, and the Sync 1.5 stack being developed by the Application Services team.
I interpret this as a classic “where to set the slider?” question where there are multiple reasonable positions on the continuum between “flexible to solve future problems” and “efficient to solve immediate problems”. On one side of the slider there is a document <https://docs.google.com/document/d/1I417io4B5CNwcHFAqlDUu0PDjd1VXXN8nv3Qw1k8Sws/edit> positing that flexibility can be achieved by separating the implementation of storage from the implementation of Sync 1.5. On the other side of the slider there is a document <https://docs.google.com/document/d/1jXu0Wd3QciblBUrkBlVMDfDldXp07fGvXygGtf7yUwI/edit> arguing that history shows that storage and Sync 1.5 are best tightly coupled. Much discussion ensued, and we conclude that the most fruitful way to achieve “rough consensus” is explore the solution space through some “running code” (an aphorism from the IETF <https://tools.ietf.org/html/rfc7282>). To that end - Grisha Kruglov is prototyping some “future-oriented” Android Components that want to manage their own storage but still (potentially) be synced across products and devices; - Mark Hammond et al are gluing the in-progress application-services Sync 1.5 + history + awesomebar stack <https://github.com/mozilla/application-services/commit/d754917ca94a2902e7358e0ed21c5094e6aa8f96> into the newly minted Reference Browser <https://github.com/mozilla-mobile/reference-browser>. What is the Reference Browser, I hear you say? "A full-featured browser reference implementation using Mozilla Android Component" -- basically, the kitchen sink of example and sample applications, and the place where we'll work through tricky aspects of integrating all of these components. Until next week, Nick
_______________________________________________ Dev-fxacct mailing list Dev-fxacct@mozilla.org https://mail.mozilla.org/listinfo/dev-fxacct
