Remove StorageDispatcher to simplify configuration system

if all our use cases can be rewritten without it

The problem (which you want to ignore ;)) is that not all of our use-cases and requirements are implemented yet.

Therefore, it is of course easy to say: "Hey, I can remove this, it's not needed."

IMHO it does not help at all to remove it, before having had an actual discussion on our technical requirements, which is supposed to happen in #1624580: Research and implement a proper design for StorageDispatcher

I'd strongly recommend to postpone this issue on that discussion (or even mark it as duplicate). However, the two of us have a disagreement here :) and I don't have any more say than @Jose.

Therefore, I think it makes most sense to delegate the decision to @heyrocker.

I was involved in the StorageDispatcher discussion and the use-case is legitimate. I agree with sun here that removing it before we have fully established the use cases it was intended for is premature.

I agree with sun, I'd like to see the use cases and technical requirements outlined and put forward before we decide whether it is worth continuing or not. We talked about whether to include it or not in the rearchitecture issue, and it appeared to me that everyone said it was my call, and I made it so now that it's in lets see where we're at before pulling it right back out again. I remember a lot of sun's potential use-cases being pretty compelling at Barcelona (although I admit that its now been too long for me to remember the specifics.)

#1624580: Research and implement a proper design for StorageDispatcher is where we need to have this discussion. It would be great if everyone would jump on that issue and check the requirements/use-cases that have been written down already, and also think about their own and new ones. :)

That said, I'm not sure whether the discussion in #1605324: Configuration system cleanup and rearchitecture contained further use-case examples. It think that most of the discussion was around "we don't know yet, so we better keep it", but we should double-check that.

Lastly, I will say that I'm already thinking about how the currently noted requirements can be resolved in combination with this issue.

Also improving this issue title, and removing the performance aspect, because I'm pretty sure that you will not be able to do a benchmark that shows a performance difference due to this change.

This issue as well as #1702080: Introduce canonical FileStorage + (regular) cache are blocking #1447686: Allow importing and synchronizing configuration when files are updated now, and since that issue is critical, I'm bumping the priority of this and the second follow-up issue to critical as well.

Re-rolled against HEAD. Fixed stale instances of StorageDispatcher throughout core. Removed irrelevant $name changes.

http://drupalcode.org/sandbox/heyrocker/1145636.git/shortlog/refs/heads/...

We resolved the interdependency by leaving out the (entire) UI for #1447686: Allow importing and synchronizing configuration when files are updated, so demoting back to normal.

Straightforward patch, and it unblocks #1702080: Introduce canonical FileStorage + (regular) cache as well as some other patches that will require rerolls now. Ship it.

Fixing whitespace and a docs line over 80 chars; no other changes.

No longer applies following http://drupalcode.org/project/drupal.git/commit/1f31a38 and there is the following merge conflict in core/lib/Drupal/Core/DependencyInjection/ContainerBuilder.php:

<<<<<<< HEAD
  public function addObjectResource($object) {
=======
  public function __construct() {
    parent::__construct();

Quickly rerolled. The init code from core/lib/Drupal/Core/DependencyInjection/ContainerBuilder.php moved to boostrap.inc's drupal_container() recently, that is why the patch did not apply anymore. I believe this should be back to RTBC as soon as it passes.

#21: config-1671080-21.patch queued for re-testing.

It helps if I don't use $this in the bootstrap.inc code. Copy-paste error. Should have been $container. :)

#25: config-1671080-24.patch queued for re-testing.

We are getting random test failures. The first run had 3 failures in searching comments, the second run had term autocomplete issues. Now going for a third run.

#25: config-1671080-24.patch queued for re-testing.

This patch needs to be updated for recent config system changes. On it.

Merged HEAD, and incorporated latest improvements from #1626584: Combine configuration system changes to verify they are compatible

Interdiff is against #14.

Testbot #813 somehow is completely tripped up and stuck on #32. Trying again.

Thanks for the reroll, should be back to RTBC then :)

Committed to 8.x. I love the sound of deleting code. Thanks all.