Fernando describes the use cases that justified the use of gaia's
preprocessor well. I think it's also useful to think about where we want
Gaia to go and the best ways to achieve what we need.
I can see needs for:
1- the system app should be modular and configurable enough to
accommodate different target devices: phone/tv/other. Even JanOS should
use a configured system, not a totally new system app.
2- some build time configuration needs to be accessible in several apps,
but it's usually an immutable setting. Using mozSettings for that is
both overkill and annoying.
3- there may be cases where we don't want to ship some files or parts of
files, if 2- is not good enough for that.
In most build systems, this is achieved by something like: (build
config) -> (static config files + preprocessor directives). Right now in
Gaia our build config is a mix of environment variables and things under
GAIA_DISTRIBUTION_DIR, and it's kind of a mess. In gecko, you can set
everything in your mozconfig. Would we be better served with something
similar? Each "distribution" providing a gaiaconfig, leading to a static
/shared/gaiaconfig.js to replace mozSettings usage, and also generating
variables to be used by the pre-processor?
Fabrice
On 09/30/2015 09:34 AM, fred wrote:
> 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:
>>
>>> 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
>>> 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]> 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
>>>
>>>
>>
> Sent from Firefox OS
>
>
>
> _______________________________________________
> dev-fxos mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-fxos
>
--
Fabrice Desré
b2g team
Mozilla Corporation
_______________________________________________
dev-fxos mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-fxos
