Refactor configuration logic about firefox-performance-dashboards

[klahnakoski]

• Must these config files be javascript, or can they be JSON?
• Are the labels related to the members of the compare?
• May the data structure be flatter? ie instead of {key: value} we use [{"id":key, "config":value}]?
• May we flatten the structure even more, assigning a platform property to each benchmark?

I have not even looked a the code yet, so these may be naive questions.

Like this

{
    "label":"Linux64bit",
    "platform":"linux64",
    "benchmarks":[{
        "id":"six-speed",
        "label":"SixSpeed(JSshell)",
        "compare":[
            {
                "id":"six-speed-sm",
                "label":"SpiderMonkey",
                "config":{
                    "color":"#e55525",
                    "label":"SpiderMonkey",
                    "frameworkId":"JSBENCH_FRAMEWORK_ID",
                    "suite":"six-speed-sm",
                    "buildType":"opt"
                }
            },
            {
                "id":"six-speed-v8",
                "label":"Chromev8",
                "config":{
                    "color":"#ffcd02",
                    "label":"Chromev8",
                    "frameworkId":"JSBENCH_FRAMEWORK_ID",
                    "suite":"six-speed-v8",
                    "buildType":"opt"
                }
            }
        ]
    }]
}

or even flatter, at the expense of a bit more redundancy:

[
    {
        "id":"six-speed-sm",
        "label":"SpiderMonkey",
        "benchmark":"six-speed",
        "platform":"linux64",
        "color":"#e55525",
        "frameworkId":"JSBENCH_FRAMEWORK_ID",
        "suite":"six-speed-sm",
        "buildType":"opt"
    },
    {
        "id":"six-speed-v8",
        "label":"Chromev8",
        "benchmark":"six-speed",
        "platform":"linux64",
        "color":"#ffcd02",
        "frameworkId":"JSBENCH_FRAMEWORK_ID",
        "suite":"six-speed-v8",
        "buildType":"opt"
    }
]

[armenzg]

Must these config files be javascript, or can they be JSON?

They don't have to be Javascript.

Are the labels related to the members of the compare?

They're... I will be honest; we could get rid of the top labels. It is only for the purpose of this widget:

It is meant to match the colours and labels of the graphs.

May the data structure be flatter? ie instead of {key: value} we use [{"id":key, "config":value}]?

If it doesn't become harder to manipulate programatically or to understand I have no objections.

May we flatten the structure even more, assigning a platform property to each benchmark?

On the most flat version we don't have "label" (text in the dropdown picker) and "platform" (probably also related to the dropdown picker). As long as it is handled somehow I'm fine with that.

[armenzg]

I'm seeing a couple more of issues being filed that would depend on this to be fixed fist. In other words, this has become a bit more important since the Android work they could see it plotted on the fx-health dashboard.

Let me know if you think you could tackle this in the next couple of weeks.