Plugin Metadata Design
The plugins (services) are basically raw. All we really know about them from at the binary perspective is their name and type (producer, consumer, filter, transition). However, an application needs to be able to gather more information. Currently, some applications are just building the metadata into their own app, possibly through source code, or just some form of config files. This is intended to address that.
- a schema - a standard structure and set of field names so applications can automatically process it. In other words, docs/services.txt is not sufficient.
- easy for module authors. This means it might be a text file provided with the module, which is obviously simple and easy for a static set of services and properties. However, some services are bridges to another modular system like ladspa or frei0r. In that case, the module needs to be able to provide the metadata programmatically at runtime. Again, it should be simple and convenient for this scenario as well.
- should be optional - an app can use a module it knows intimate knowledge without having the framework filter it out for lack of metadata
- contain enough information to let the app generate a UI - both the service browser and the service editor
- contain default values for parameters
- accommodate future requirement for animation (mutable properties with key frames and interpolation) to replace current system of service-specific animation
- a module may call mlt_repository_register_metadata for each of its services
- the module will supply a properties tree to mlt_repository_register_metadata
- the framework will take care of free-ing the metadata properties memory so modules do not have to worry about their lifetime
- add a mlt_properties_parse_yaml variant to mlt_properties_load so modules can author its metadata in a very small subset of YAML. I do not want to add a XML parser to the framework. I could use the existing mlt_properties_load, but the file format is already similar to yaml. And I like yaml over xml and something unique. Of course, nothing prevents a module from using its own xml parser, but I want don't want to add the parser requirement to a framework service (mlt_properties).
- add YAML Tiny (PLEASE READ) support to mlt_properties.
- remember, modules don't have to have a yaml file representing their metadata. it can all be done programmatically.
- modules can install their metadata file(s) in $(datadir)/<module>/metadata/
- modules can load their metadata file(s) using mlt_environment("MLT_DATA")/<module>/metadata/<locale>.yml
- schema version - in case the schema changes, then apps can be programmed for flexibility
- service implementation version
- taxonomy of tags: Audio, Video, Luminance, Chrominance, Frequency, Wipe, Distortion, Delay, Amplifier, Pitch, Bandpass, Spectral, Lowpass, Highpass, Comb, Utility, Waveshaper, Generator, Equalizer, Flanger, Compressor, Limiter, Expander, Oscillator, Measurement, Gate, Simulator, Reverb, Filter, Chorus, Notch, Phaser, Allpass, Modulator, Dynamics, Mixer, Motion, Interlace, Temporal, Size, Transform, Resample, Noise, Sharpness * Dublin Core Elements v1.1: identifier, creator, contributor, language, title, description, type
- use ISO 639-1 codes as supported by gettext.
- The glib g_get_language_name() contains code for getting this from the environment.
- The framework will provide this list of these locale names to the mlt_metadata callback.
- The framework exposes a mlt_repository_metadata( service_type, service_name ) function to query and lookup metadata. It returns mlt_properties.
- The framework expects modules to include a mlt_metadata callback if it can provide metadata.
- This system prevents modules from having to register metadata at load time reducing startup time.
- The mlt_metadata callback will supply the service_type, service_name, and locales as a null-terminated array of strings.
- metadata shall be cached in the repository along with the locale code.
- Modules that provide presets must implement the mlt_presets callback, which gets a service_type and service_name as parameters and returns a mlt_properties.
- presets schema TBD
- widget taxonomoy: knob, slider, radio, checkbox, spinner, combo, menulist, listbox, color, textbox, timecode, fileopen, filesave, curve, color, font, rectangle (for mlt_geometry)
- If icon/filename is relative, it is relative to $(datadir) ($datadir is e.g. /usr/share/mlt)
- The current MLT Tiny YAML implementation only supports 2 space characters for indentation!