[experimental][discussion] introducing baseBase setting to support base inheritance for groups

[caridy]

With the upcoming SPDY support, we will have more and more applications using combine: false (combo is an anti-pattern when serving assets using SPDY), also, we will see some benefits when serving all assets from the same domain (yes, domain sharding is also an anti-pattern when using SPDY). In an effort to consolidate the inheritance of configurations from groups from the master settings to minimize the amount of settings to define per group, we are proposing to have a new configuration option called baseBase.

baseBase works similar to comboBase, which has to be completed with the root value to form the path to a module. If baseBase is specified at the top level, along with comboBase, and root is defined at the top level and per group, then it will be simpler to infer the base value per group based on the global baseBase.

The ideal configuration will be:

YUI({
      baseBase: 'http://mycdn.com/path/to/',
      comboBase: 'http://mycdn.com/path/to/combo?',
      root: 'yui-3.1.5.0/',
      groups: {
           foo: {
               root: 'bar/'
           },
           bar: {
                root: 'foo/'
           }
      }
})

In the example above, whether we use use combine or not, the base does not have to be defined, because it can be computed based on baseBase and the corresponding root value.

Few more thoughts:

• base is king. If it is set, it will not be combined, so this change is BC.
• baseBase CANNOT be infer from parsing the seed url, it always have to be defined manually (BC too).

Open questions:

• should combine be inherited/computed as well?

[yahoocla]

CLA is valid!

[ericf]

I wonder if we should take a different approach here and have a new/better configuration API that's opt-in behind a flag?

Right now, the configuration we need to setup if very, very confusing for people, and adding baseBase just makes matters worse in that regard. Instead of glomming-on more ambiguous configuration options, can we step back, create the config values we really want, and put the processing of those values behind a feature flag?

[okuryu]

Updated the HISTORY.md in ed102b9.