Jean-Marc Desperrier wrote: > ICU is a massive, huge juggernaut. It fits the bill in professional > application that have no download size constraints, and no > requirement to support the low end of installed memory size. OS > support is incredibly more efficient.
Jean-Marc, I don't agree with everything you said but I do agree with this part, which I think people might be glossing over too easily. I don't understand the fixation on ICU as *the* solution to this problem. If the EcmaScript specification is so complicated and so unusual in its design that it cannot be easily implemented using widely-deployed system i18n APIs, then IMO that spec is broken. But, I highly suspect that it is quite possible to implement that spec with OS-provided libraries. Window and Mac have extensive internationalization APIs. Why not use them? I am also unsure about the comments that say imply that even stock ICU is not a good choice for implementing this API. Is it *required* to modify ICU to implement the JS API, or is it just inconvenient or (slightly?) inefficient to use the stock ICU API? We can ship ICU as a system library on B2G. Some Linux distributions apparently ship ICU as a system library so we may be able to make an ICU system library a runtime prerequisite for Firefox on Linux, or we could just make Firefox on Linux 20% bigger (I don't think Linux users are that particular about the download size). According to previous messages in this thread, Android has ICU as a system library, that just isn't exposed as an official NDK library. However, I've read that it is possible to dlopen the system libraries and use them; you should just be extra-careful about handling the case where the libraries are different or missing (e.g. renamed). I think it is worth exploring doing this, and falling back to "no JS i18n support" or "we must download a bunch of ICU data" when things fail. Also, Android is similar to an open-source project. Perhaps we could contribute the glue to provide a usable system ICU to NDK applications as a long-term solution. Then the pain and uncertainty for Android would be somewhat bounded in time. Granted, the above ideas are a lot more work than just using ICU everywhere. I don't know *how* much more work it would be. But, I think that if an engineer came to us and said "Give me one year and I will reduce your download size by 20% in one year" then I hope we'd consider hiring him to do that. So, IMO, the extra work to save download size is justifiable if the feature itself is really a high priority. We may be able to just take the 20% hit on download size on Mac too without being too concerned. We didn't/aren't implementing stub installer on Mac, right? And, we've been shipping universal binaries on Mac (did we stop that yet). Those two things indicate to me we're less concerned about download size on Mac. If so, then we may be able to get away with just two implementations: One ICU, and one Windows API. Even if we decided that ICU is the only choice for all platforms, there is a middle ground between "Must block the startup of Firefox during installation on the download of ICU data" and "Delay downloading the ICU data until a web page requests it." We could add an updater for the ICU data that downloads/installs/updates the ICU data into the Firefox profile separately from Firefox installation and update (so the user doesn't have to wait on the ICU data to download to use Firefox during installation or update). Note that we already do (did?) something similar, downloading ~45MB of safe browsing data on first use. (Actually, I think that we could maybe do something like this for WebRTC stuff too, which IIRC is about ~1.5MB of object code.) Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
