On 4/29/16 11:30 AM, sn...@snorp.net 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 dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
