I just found Preprocessor.js is officially deprecated by its author https://github.com/dcodeIO/Preprocessor.js That is a big red flag to me.
The Preprocessor.js author is in favor of the successor MetaScript. But those two projects have not much maintainers, and last commit are recorded at 2014... Though adding some sort of |#IFDEF| support in Gaia might help vendors patch their gaia with flags and not breaking the existing code. We should propose a better alternative instead of Preprocessor.js if |#IFDEF| support is the way to go. mozSettings does has its issue, but I'd rather stick with it for 2.5 to keep the maintainability if we don't have better solution at this moment regards -- Fred On Wed, Sep 30, 2015 at 5:35 PM, Fernando Jiménez Moreno < [email protected]> wrote: > 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 > > 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
