Section 3.1.1 of the provisional AL specification describes the different states of OpenMAX AL objects. Specifically it says:
Unrealized (initial state): The object is alive but has not allocated resources. It is
not yet usable; its interfaces’ methods cannot yet be called.
This means the application would have to create an object first using the engine and then call Realize on its object interface to be able to query some object-specific interfaces. I guess that the ConfigExtensionsItf can also not be used until the object has reached the Realized state.
So, let’s assume I have some implementation of OpenMAX AL which needs to allocate resources for some objects that are not covered by the specification. Without those resources the object would not be able to work properly (or not work at all). So, I would expect from the application to set some key-value pairs via the ConfigExtensionsItf for the object to initialize itself correctly.
How could this problem be solved? One idea would be to (mis-)use the engine’s ConfigExtensionsItf before creating the object in question. Another would be to initialize the object with some default values nevertheless, although it would be quite useless from the application’s view, but then again I think this would make the application more portable.
Any suggestions how to solve this? Or did I even misunderstand the usage of the ConfigExtensionsItf?