Hello,
> On Sep 30, 2015, at 9:23 AM, Fred Lin <[email protected]> wrote:
>
> According to https://bugzilla.mozilla.org/show_bug.cgi?id=1191770#c20
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1191770#c20>
>
> I surprisingly found we have preprocessor support in gaia system.
>
> As in comment there are PROS and CONS between
> 1. using mozSettings to enable feature
> 2. define IFDEF area and process flags by Preprocessor.
Could you explain which CONS you see with the current usage of the preprocessor
vs mozSettings, please?
You could argue that it adds some noise into the code. And I could agree. But
I'd also argue that mozSettings adds some noise as well by adding an extra
async check step.
> We used to go with 1. mozSettings, but 2. flag features behind preprocessor
> may help save some footprint in TV or other form factor devices. (and it
> might make un-runable plain code in browser)
>
As I already mentioned in Bugzilla and in other email thread about this, the
reasons why we chose to add the preprocessor functionality, with the blessing
of the build module peers, is to have a build time way to enable/disable a
feature in the following scenarios:
- To keep a feature disabled during the development process. This allows a more
fluid dev process as we can land not fully functional code without affecting
other parts of Gaia. If we don't meet a specific deadline, we just need to keep
the feature flag disabled and the incomplete code will just not be part of the
build. That's the current case of Firefox Sync [1].
- To disable a feature because of a last minute security or functional issue.
We are not perfect and we can miss bugs that can affect our products in several
ways. When we close a release with new features and we give it to our partners
so they can go through their QA and certification process, a lot of bugs cause
in and by these new features may still be found. If these bugs are critical
enough, the partner may choose to kill the feature causing these issues. We
need an easy way to do that.
- To disable a feature that does not fit into a specific product. Firefox OS is
starting to be used in several different products. Some of these products may
not take everything from the core OS. For example, the TV shipped without
Firefox Accounts and we had to remove every single line related to Firefox
Accounts from that tree. And now we want it back. So we needed to put that code
back again. Wouldn't it have been easier to have a single flag to do that for
us? Think about IoT devices or the smart feature phone. Not all features fit in
there.
Now, you say that mozSettings is the current way to enable/disable features.
And while that's true and I agree mozSettings is the way to go for some cases,
mozSettings also has different issues. It requires an extra permission and it
performs runtime checks that are error prone and could affect the performance.
As a Settings peer you probably know this, but we had this issue again with
Firefox Accounts in the past, we were using a setting to decide if we wanted to
show or not the FxA menu in the main Settings menu. That affected the
performance and the UX. The user could see how the menu was shown for a brief
moment to be hidden just after that. The app start up time is already hard
enough to tune to keep adding more of these checks when we have alternative
approaches that has zero impact in performance. Also, with mozSettings we can't
remove the dead code from a disabled feature. The code is still there,
polluting the DOM and the styles and taking disk space.
Now that we want to be working on a train based model, I think having an easy
and effective way to enable/disable features at build time like this is
important.
[1] https://mxr.mozilla.org/gaia/source/Makefile#89
> I'd like to rise the discussion here about
>
> 1. If we should go with preprocessor.
> 2. If we allow to use it, WHAT situation shall we use preprocessor or
> mozSettings?
I would say that the preprocessor is a good fit to enable/disabled features in
any of the scenarios I mentioned above:
- During the development process of a feature is quite easy to use it to remove
it afterwards when the feature is stable enough.
- If we think a core feature is not a good fit for all our products or
partners, we should add an easy way to disable and remove it.
- If the startup path of an app depends on a feature check, we should probably
use the preprocessor.
For the rest of the cases, mozSettings is ok as long as the addition of its
permission is something we can live with.
Cheers,
/ Fernando
_______________________________________________
dev-fxos mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-fxos
