caching is atm a bit all over the place in Symfony2 and unfortunately we will not have a proper cache component (or blessed 3rd party lib) by 2.3 .. but we can think about what kind of things we could today to prepare for the day when we do have such a thing.

In the recent discussions about the "Cache component", I had the impression that it mostly aims at having something like Doctrine Cache, APC or the like. ConfigCache is very different from that, but nonetheless it might end up in such a component.

@lsmith77 the ConfigCache here is a different thing than the Cache component, with a different use case.

There is a small issue in your description through. the resources are also used by the ConfigCache part. They are not only for loaders.

The main drawback of such a split is the BC break IMO. Otherwise, I'm all in favor of splitting things as the loaders and the Definition stuff are 2 different unrelated features (except for the fact that you will often use a loader to build the array passed to the Configuration)

The "Resources" (ResourceInterface et al) are not even used by loaders. Loaders only talk about loading "resources", but that's just strings identifying something.

ResourceInterface is for ConfigCache only.

Well, resources are handled by the child classes of the loader implementing the actual loading logic, as the way resources are gathered also depend of the case. See the loader implementations in the DI and Routing components.
The loaders are the objects knowing how to build the ResourceInterface instances as they are the only place knowing which file they are reading.

@stof do you still consider this split worthwhile?

I think it's not worthwhile

Ok, you guys decide – feel free to close it.