QOM types and the QOM graph are externally visible: * qom-list-types returns QOM type names and parents.
Fine print: the result is limited to concrete types by default. Aside: that's the only way to figure out whether a type is abstract. Interface design fail. The result can optionally be limited to sub-types of a certain type. * qom-list-properties returns a named type's static properties. * qom-list returns an object's properties. This lets clients traverse the QOM graph. * qom-get returns a property's value. * qom-set changes a property's value. * -object and object-add create a QOM object of a certain type with certain property values. The type must be a sub-type of "user-creatable". * Types are identified by name. * Objects and properties are identified by QOM path. An absolute QOM paths is the path within the composition tree starting at the root. Partial paths are a convenience you don't want to understand. What promises do we make regarding the stability / backward compatibility of these externally visible entities? The QMP command documentation is silent on it. A user could reasonably assume that the general QMP stability promise extends to all of QOM. Does it? Was that the intent when we created qom-list, qom-set, qom-get? Andreas, do you remember? Is it practical given the current state of affairs? Is it a good idea?
