169 lines
7.4 KiB
Text
169 lines
7.4 KiB
Text
[grid="all"]
|
|
`------------`-----------------------
|
|
*State* _Idea_
|
|
*Date* _2008-09-03_
|
|
*Proposed by* link:Ichthyostega[]
|
|
-------------------------------------
|
|
|
|
|
|
|
|
Describe pluggable modules by a "Feature Bundle"
|
|
------------------------------------------------
|
|
This proposal builds upon Cehteh's Plugin Loader, which is the fundamental mechanism for integrating variable parts into the application.
|
|
|
|
It targets the special situation when several layers have to cooperate in order to provide some pluggable functionality. The most prominent example are the "effects plugins" visible for the user. Because, in order to provide such an effect
|
|
|
|
* the engine needs a processing function
|
|
* the builder needs description data
|
|
* the gui may need a custom control plugin
|
|
* and all together need a deployment descriptor detailing how they are related.
|
|
|
|
|
|
|
|
|
|
Description
|
|
~~~~~~~~~~~
|
|
The Application has a fixed number of *Extension Points*. Lumiera deliberately
|
|
by design does _not build upon a component architecture_ -- which means that plugins
|
|
can not themselves create new extension points and mechanisms. New extension points
|
|
are created by the developers solely, by changing the code base. Each extension
|
|
point can be addressed by a fixed textual ID, e.g. "Effect", "Transition", ....
|
|
|
|
Now, to provide a pluggable extension for such an Extension Point, we use a *Feature Bundle*
|
|
Such a Feature Bundle is comprised of
|
|
|
|
* a Deployment Descriptor (provided as "structured data" -- TODO: define the actual data format)
|
|
* the corresponding resources mentioned by this Deployment Descriptor
|
|
|
|
The Deployment Descriptor contains
|
|
|
|
* Metadata describing the Feature Bundle
|
|
- ID of the Extension point
|
|
- ID of the Bundle (textual ID)
|
|
- ID of origin / provider (could be a domain name)
|
|
- Category (textual, tree-like)
|
|
- Version number (major, minor)
|
|
- required Extension point version number (or Lumiera version no.?)
|
|
- Author name (utf8)
|
|
- Support email (utf8)
|
|
- textual description in a single line (utf8)
|
|
* A List of Resources, each with:
|
|
- ResourceID
|
|
- SubID
|
|
- Type of Resource, which may be
|
|
. Plugin
|
|
. Properties
|
|
. Script
|
|
. ...?
|
|
|
|
- one of:
|
|
. the Resource provided inline in suitable quoted form (for textual resources only)
|
|
. an URL or path or similar locator for accessing the Resource (TODO: define)
|
|
- Additional Metadata depending on Type of Resource (e.g. the language of a script)
|
|
|
|
|
|
|
|
We do _not_ provide a meta-language for defining requirements of an Extension Point,
|
|
rather, each extension point has hard wired requirements for a Feature Bundle targeted
|
|
at this extension point. There is an API which allows code within lumiera to access
|
|
the data found in the Feature Bundle's Deployment Descriptor. Using this API, the code
|
|
operating and utilizing the Extension Point has to check if a given feature bundle is
|
|
usable.
|
|
|
|
It is assumed that these Feature Bundles are created / maintained by a third party,
|
|
which we call a *Packager*. This packager may use other resources from different
|
|
sources and assemble them as a Feature Bundle loadable by Lumiera. Of course, Lumiera
|
|
will come with some basic Feature Bundles (e.g. for colour correction, sound panning,....)
|
|
which are maintained by the core dev team. (please don't confuse the "packager" mentioned here
|
|
with the packager creating RPMs or DEBs or tarballs for installation in a specific distro).
|
|
Additionally, we may allow for the auto-generation of Feature Bundles for some simple cases,
|
|
if feasible (e.g. for LADSPA plugins).
|
|
|
|
|
|
The individual resources
|
|
^^^^^^^^^^^^^^^^^^^^^^^^
|
|
In most cases, the resources referred by a Feature Bundle will be Lumiera Plugins. Which means,
|
|
there is an Interface (with version number), which can be used by the code within lumiera for
|
|
accessing the functionality. Besides, we allow for a number of further plugin architectures
|
|
which can be loaded by specialized loader code found in the core application. E.g. Lumiera
|
|
will probably provide a LADSPA host and a GStreamer host. If such an adapter is applicable
|
|
depends on the specific Extension point.
|
|
|
|
The ResourceID is the identifyer by which an Extension point tries to find required resources.
|
|
For example, the Extension Point "Effect" will try to find an ResourceID called "ProcFunction".
|
|
There may be several Entries for the same ResourceID, but with distinct SubID. This can be used
|
|
to provide several implementations for different platforms. It is up to the individual Extension
|
|
Pont to impose additional semantic requirements to this SubID datafield. (Which means: define
|
|
it as we go). Similarly, it is up to the code driving the individual Extension point to define
|
|
when a Feature Bundle is fully usable, partially usable or to be rejected. For example, an
|
|
"Effect" Feature Bundle may be partially usable, even if we can't load any "ProcFunction" for
|
|
the current platform, but it will be unusable (rejected) if the proc layer can't access the
|
|
properties describing the media stream type this effect is supposed to handle.
|
|
|
|
Besides binary plugins, other types of resources include:
|
|
* a set of properties (key/value pairs)
|
|
* a script, which is executed by the core code using the Extension Point and which in turn
|
|
may access certain interfaces provided by the core for "doing things"
|
|
|
|
Probably there will be some discovery mechanism for finding (new) Feature Bundles similar
|
|
to what we are planning for the bare plugins. It would be a good idea to store the metadata
|
|
of Feature Bundles in the same manner as we plan to store the metadata of bare plugins in
|
|
a plugin registry.
|
|
|
|
|
|
|
|
|
|
Tasks
|
|
^^^^^
|
|
|
|
|
|
Pros
|
|
^^^^
|
|
|
|
|
|
|
|
Cons
|
|
^^^^
|
|
|
|
|
|
|
|
Alternatives
|
|
^^^^^^^^^^^^
|
|
Use or adapt one of the existing component systems or invent a new one.
|
|
|
|
|
|
|
|
Rationale
|
|
~~~~~~~~~
|
|
The purpose of this framework is to decouple the core application code from the details of
|
|
accessing external functionality, while providing a clean implementation with a basic set of
|
|
sanity checks. Moreover, it allows us to create an unique internal description for each
|
|
loaded module, and this description data e.g. is what is stored as an "Asset" into the
|
|
user session.
|
|
|
|
Today it is well understood what is necessary to make a real component architecture work.
|
|
This design proposal deliberately avoids to create a component architecture and confines
|
|
itself to the bare minimum needed to avoid the common maintenance problems. As a guideline,
|
|
for each flexibility available to the user or packager, we should provide clearly specified
|
|
bounds which can be checked and enforced automatically. Because our main goal isn't to
|
|
create a new platform, framework or programming language, it is sufficient to allow the
|
|
user to _customize_ things, while structural and systematic changes can be done by the
|
|
lumiera developers only.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Comments
|
|
--------
|
|
|
|
From a fast reading, I like this, some things might get refined. For example I'd strongly suggest to
|
|
make the Deployment Descriptor itself an Interface which is offered by a plugin, all data will then
|
|
be queried by functions on this interface, not by some 'dataformat'. Also Resource ID's and a lot
|
|
other metadata can be boiled down to interfaces: names, versions, uuid of these instead reiventing
|
|
another system for storing metadata. My Idea is to make the link:Plugin/Interface[] system self-describing
|
|
this will also be used to bootstrap a session on itself (by the serializer which is tightly integrated)
|
|
-- link:ct[] [[DateTime(2008-09-04T09:28:37Z)]] 2008-09-04 09:28:37
|
|
|
|
Back to link:Lumiera/DesignProcess[]
|