226 lines
7.4 KiB
Text
226 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[]
|