My apologize that build/preprocessor.js in gaia is a total different thing with preprocessor.js library on github. So my above comments is invalid.
Fernando Jiménez Moreno wrote:
Fernando Jiménez Moreno wrote:
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
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 momentAs 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,/ FernandoregardsFred
--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: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.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
Sent from Firefox OS
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
