What are the distributions of memory and flash sizes for the devices people currently run Fennec on? It'll be almost impossible to have a good discussion about Fennec size without those numbers. I seem to remember that is data we felt was okay to collect.
On Sun, May 1, 2016 at 2:21 PM, Boris Zbarsky <[email protected]> wrote: > On 4/29/16 11:30 AM, [email protected] wrote: > >> The Fennec team has been very clear about why they oppose inclusion of >> ICU in bug 1215247. >> > > Sort of. There's been a fair amount of moving of goalposts to get from > https://bugzilla.mozilla.org/show_bug.cgi?id=1215247#c14 to > https://bugzilla.mozilla.org/show_bug.cgi?id=1215247#c43 as far as I can > tell. > > I sympathize with the Fennec team's position here: The amount of code in > libxul keeps growing (not always by as little as possible, I agree!) as we > add support for more stuff the web is coming to depend on, but some of the > features being added are perhaps not a big deal in the markets that want a > small APK download. It's not clear to me who (if anyone) knows what > features these are; clearly the JS Intl API (yes, not the only reason to > include ICU) is one of them, but are there others we've identified? > > Of course https://bugzilla.mozilla.org/show_bug.cgi?id=1215247#c43 more > or less flat-out disagrees with the suggestion that we should have fewer > Gecko configurations, on a much broader front than ICU support... > > I know we have places where we use more space than we should in Gecko, and > in particular some places where we have traded off space for speed by > having largish static data tables instead of more dynamic checks... not to > mention having static bindings code instead much smaller dynamic XPConnect > code. This tradeoff was very conscious, akin to Fennec's decision to not > compress .so, but may have been the wrong one for Fennec in practice. > > If we, as an organization, really want to try to reduce the size of the > Fennec APK, and are actually willing to put platform resources into it > (which requires either hiring accordingly or starving other goals, in the > usual way), then we should do that. So far I've unfortunately seen > precious little willingness to staff such an effort appropriately. :( > > This type of attitude is why we have people in the Firefox org wanting to >> axe Gecko. >> > > For the Android case, I expect the only viable replacement that hits the > desired size limits would be an iOS-like solution, right? That is, a UI > using whatever browser engine is already installed on the device? > > Just to be clear as to what our real alternatives are here. > > The engineers in Platform consistently want to dismiss mobile-specific >> issues >> > > I think you're painting with a _very_ broad brush here. > > -Boris > > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
