> On Sep 30, 2015, at 4:38 PM, Fred Lin <[email protected]> wrote: > > I just found Preprocessor.js is officially deprecated by its author > https://github.com/dcodeIO/Preprocessor.js > <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... >
Sorry, but I can't se how the deprecation of a third party tool completely unrelated to Gaia could be a "big red flag" here. In any case, these tools seems to be Javascript only. The simple preprocessor that we built for Gaia is for HTML, JS and CSS, > 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. > I am afraid that neither the data sync team or the build peer involved in the preprocessor work could find a better alternative, but I would really love to hear one. > 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 As I tried to explain in my previous email, mozSettings is not providing us what we need for some specific cases like Firefox Sync. If you can provide an alternative approach, I'll be happy to use it. But so far the preprocessor is what we have. Cheers, / Fernando > regards > -- > Fred > > On Wed, Sep 30, 2015 at 5:35 PM, Fernando Jiménez Moreno > <[email protected] <mailto:[email protected]>> wrote: > Hello, > >> On Sep 30, 2015, at 9:23 AM, Fred Lin <[email protected] >> <mailto:[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 > <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
