Global resource loading and management

[Radikalizm]

An idea about a unified system for resource loading and resource management has been haunting my mind lately, I've even gone as far as to do some prototyping (read: hacking with irrlicht's and my own engine's internals) to see how this would work out

The concept goes like this:

Say we have a general resource interface class, called IResource; this class would do nothing but store 2 pieces of information: a name, and a type identifier.
We also have an interface class called IResourceManager, which has methods for loading, finding, removing and any other possible standard interaction with resources of a specific type.

We could now set the IResource class as a parent class for all our assets which can be loaded from disk or from memory (eg. ITexture, IImage, IMesh, etc.), and we could design an implementation based on the IResourceManager interface for handling each specific type of resource (based on filetypes), effectively moving away this responsibility from systems which in my opinion should not be tasked with loading resources (eg. the IVideoDriver class)

Now, we could design a system based on the IResourceManager interface which would have the functionality to register other resource managers, giving it the ability to load any kind of resource by looking for a fit manager throughout its collection of registered managers
Clients using the system would now also have the ability to construct their own kinds of resources together with suited resource managers, which they could then register with the global resource manager, making it possible to load any kind of resource through this one interface (this is how irrlicht's image loaders and writers currently work)


The system described above works beautifully, but when you think about it for a while you'll notice that some problems arise

Since the global resource manager has the ability to load resources of any kind, it can only return them in the form of their parent class (the IResource class)
By design, this class has no way of telling the client what this resource contains, it can only tell which kind of resource it is representing
There are a couple of possible solutions to this problem:

1. Let the client do a type cast on the returned IResource after checking which kind of resource it is representing (which sounds like a bad idea)
2. Provide in-engine methods to convert resources to their correct types (which also doesn't really sound like a good idea, and which could limit custom resource implementations)
3. Use an attribute system to modify resource attributes through the IResource interface (this would be more elegant, but would be a pain to implement and to test for correctness, since a resource could be modified a lot)


Some feedback on this idea and its problems would be nice, I hope I explained the concept well enough, but if something isn't clear you can just ask

[devsh]

I use resource HANDLES like in Horde3D, being typecasts of 32 bit integers. Then you query the engine for an actual pointer to the resource

[Radikalizm]

I use resource HANDLES like in Horde3D, being typecasts of 32 bit integers. Then you query the engine for an actual pointer to the resource

This could be an option too, but would be too intrusive against my existing architecture

My idea was partially inspired by some papers I read about resource management in Bungie's Halo engine