MXM Basics

MXMObject (MXMObject.h)
The MXMObject is the base class for all C++ objects passed to or returned by interface methods: it defines a small set of methods that should help the receiver to understand what kind of informations the object is carrying, to support an interoperable environment composed by engines from different vendors. All methods have a basic “implementation”, that throws an exception telling us that there is actually no implementation (…), thus not forcing the coder to implement all of them (but doing that should be appreciated).
1) virtual string toString() const : should return a human-readable representation of the object
2) virtual const void* getData() const : should return some data suitable to rebuild an equivalent representation of the object
3) virtual size_t getDataSize() const : should return the length of the data above
4) virtual string getContentType() const : should return a string to identify the kind of the data above

MXMEngine (MXMEngine.h)
This is the simple base class for every engine implementation: it gives derived classes the support for engine-level parameter management.
Parameters should arrive to the engine flowing from the command line and a config file. Command-line parameters should have precedence over those in the config file.
Every parameter arrives at the engine with a scope, a name and a value: the scope indicates the origin and applicability of the parameter, the name define its meaning (known to the engine implementation); this mechanism is string-evaluation based, so prone to bogus, unmanageable at compile time.
Actually we recognize three kinds of scope:
1) engine-type level: every engine implementation refers to an engine-type, or engine-purpose: mp21file, rel, mediaframework, and so on; the scope is the name of the engine type
2) engine-name level: every engine has a (unique) name; the scope is the engine name
3) config-file level: the scope is “EngineConfig”
Engine-type and Engine-name scopes have no precedence the one on the other, so consecutive values of the same parameter (name) within any of these scope will override precedent ones; “EngineConfig” parameters will instead be overwritten by parameters at engine-type or engine-name level. We think engine-name parameters SHOULD have precedence over engine-type ones

The “final” template-implementation of every library-level engine factory: usually no specification of this template is necessary, since it almost performs a new of the specified engine type on coder’s demand: one would just give it contextual names for ease

namespace smartrm
namespace RelEngine
class Engine { … };

class Factory : public core::engines::management::EngineFactory< Engine > { };

Loggable (MXMLoggable.h)
The Loggable base class is just a basic manager for a log4cxx::LoggerPtr, who is initialized with the logger name passed to the constructor: extending this class will result in the ability to log errors, warnings, debug informations using log4cxx facilities, and to throw / catch exceptions with the MxM exception macros.