Context system

Here's a context system I wrote to allow config overrides per hostname, it should only need to be adopted a little bit for actual domain records: http://privatepaste.com/ca7c77271f

wow, nice
thanks!!

I should also note, this works for reading the configuration files, but I'm not sure how the config actually gets written.

#4 looks like nope
commited refactored http://drupalcode.org/sandbox/podarok/1917942.git/commit/c1d1f534b7ff6f0... here
and http://drupalcode.org/sandbox/podarok/1917942.git/blob/c1d1f534b7ff6f09f... this 2 functions calls brokes config system.
Will looks at the code tomorrow and fix it

EDIT: fixed
looks like it was container dic compiling issue.
Regeneration helps me
#2

Can You explain how Your subscriber defined at Bundle?
Cause I`ve got error
Fatal error: Call to a member function get() on a non-object in \core\includes\config.inc on line 105
about

  static function getSubscribedEvents() {
    $events['config.context'][] = array('configContext', 20);
    $events['config.load'][] = array('configLoad', 20);

Looks like there are no yet any config.context and config.load at this stage

The code with commented lines here

Wow, this works quite nicely :-)

Here's a cleaned up version of #2 and #5 against the sandbox...

Once applied, copy a config file into sites/default/config_XX/active) and prefix the filename with e.g. domain.config.one_drupal8_dev. (where one_drupal8_dev is the machine name of a domain); then change some variables (e.g. the site name), clear the cache, and you should see your variables have a different value depending on the active domain.

I tested this with the sitename variable and system.site.yml.

What's still missing is a way to set config values via the UI. I think core's locale module has the same problem, and it looks like this is going to be solved in contrib via the config_translation module; maybe that can serve as inspiration.

Eventually this should also consider "domain x language" combinations; i.e. we need to figure out how to allow values which are both domain-specific and multilingual. Conceptually we might be able to borrow ideas for that from the domain variable module, which tries to solve the same thing for D7.

I'd like to check that we have our classes in order. Specifically, we should look at the services we provide

What do you mean? They seem fine to me; they both make sense to me at least. I guess the subscriber would not need to be "exposed as a service", but from what I understand this is the standard way to register event subscribers in D8, right?

Attached patch moves everything into a separate module named Domain Config. Not sure whether the namespace is the correct one, but everything should still work the same.