I also posted the question on the *Bug 939056,*<https://bugzilla.mozilla.org/show_bug.cgi?id=939056>If NFC function is disabled at runtime, should the navigator.mozNfc object also NOT exist, or should it be there, but with methods behaving as no-ops?
As for not worrying about storage usage, I agree it might not matter much in practice. Storage is getting quite plentiful on smartphones, and a few kilobytes isn't going to be missed as soon as the user snaps a single 8 Mpix picture at normal compression. -Garner On Mon, Dec 2, 2013 at 2:20 AM, Thomas Zimmermann <[email protected]>wrote: > Hi, > > In my opinion, we shouldn't allow for enabling/disabling arbitrary > components on our development phones, otherwise we'll end up with tons > of different combinations. And the resource savings are probably not > worth it. > > Using runtime detection of available features seems much cleaner. if > there are race conditions between the detection code and something else, > we should fix them instead. > > We had this discussion for NFC, and I think it would be perfectly fine > to handle NFC detection completely within the NFC daemon. If NFC is not > available on the device, the NFC daemon would just do nothing (and maybe > reply with error message to Gecko). The same might be doable for RIL. > > Best regards > Thomas > > > On 02.12.2013 06:15, Vicamo Yang wrote: > > Hi all, > > > > Recently we have a few bugs regarding the variety of features of > > different devices/platforms. See bug 920551 [1] and bug 939056 [2]. > > The problem is: shall we allow --disable-foo in per device configuration? > > > > Right now we have a file named 'default-gecko-config' inside gonk-misc/. > > The file contains 23 default |ac_add_options ...| lines and several of > > them are further controlled by environment variables exported in > > '.config' and/or '.userconfig'. > > > > Besides, there is also another way to inject such compile time options. > > The 'Android.mk' file in same gonk-misk/ directory suggests one may > > assign "GECKO_CONFIGURE_ARGS" in any other "Android.mk" files, and the > > value will be passed as "CONFIGURE_ARGS" env variable to Gecko during > > the configure stage. The best home for this variable is per device > > 'BoardConfig.mk' for sure. > > > > So back to the original problem: shall we allow --disable-foo in per > > device configuration? That is: shall we allow assigning > > "GECKO_CONFIGURE_ARGS" in per device 'BoardConfig.mk'? > > > > I would say YES. My 2 cents: > > > > 1) Code size. > > > > Back to bug 864485 [3], migrating Telephony IPC from frame messaging to > > IPDL, Telephony DOM code was then built on ALL platforms just like what > > we have for MobileMessage. By ALL, I mean it's compiled even on > > Windows. Then I got a regression mail saying the built binary size grew > > 1% after that patch on platforms didn't have WebTelephony before. Taking > > current /system/lib/libxul.so for example, 1% means 230KB. I heard > > there is some kind of delayed loading tech in use, but this still comes > > to my mind first when we were to built-in some dead code in final > > executables. > > > > 2) Runtime detection may lead to a certain problem. > > > > The two bugs, 920551 and 939056, are for enabling/disabling a certain > > B2G feature(s) on different devices. These features come with DOM APIs > > for sure. For now we're to hide APIs from user content when it's not > > available. Runtime detection is suggested but it takes time. It > > follows the first call to retrieve the availability of such feature > > should only be made after we're fully confident/determined there is no > > such feature on that device. For example, FTU need to know whether does > > the device implement RIL APIs or not before it's to display a menu item > > for "Import SIM contacts". Such calls have to be delayed after runtime > > detection is done, and again these detections take some time. Why not > > just skip these detections on devices that have no such feature at all? > > > > 3) How and why > > > > Till now, all devices have their own Gecko binaries. They're built > > directly from the source code and each of them is basically different > > from each other. No any devices share Gecko binaries at the time at > > all. Some devices have even additional patches to Gecko applied, and > > some replaces built-in components with their own. Mozilla just can't > > stop device makers from compiling Gecko by their own. And we just > > shouldn't do so, either. The thing we should only care is to provide > > unified Web API interfaces to users, not binary monopoly to device > makers. > > > > So, what would you say? > > > > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=920551 > > [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=939056 > > [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=864485 > > _______________________________________________ > > dev-b2g mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-b2g > > _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
