Ichthyostega
b556d2b770
Some sections of the Lumiera website document meeting minutes, discussion protocols and design proposals from the early days of the project; these pages were initially authored in the »Moin Moin Wiki« operated by Cehteh on pipapo.org at that time; this wiki backed the first publications of the »Cinelerra-3« initiative, which turned into the Lumiera project eventually. Some years later, those pages were transliterated into Asciidoc semi-automatically, resulting in a lot of broken markup and links. This is a long standing maintenance problem problem plaguing the Lumiera website, since those breakages cause a lot of warnings and flood the logs of any linkchecker run.
147 lines
5.3 KiB
Text
147 lines
5.3 KiB
Text
Design Process : Interface Namespaces
|
|
=====================================
|
|
|
|
[options="autowidth"]
|
|
|====================================
|
|
|*State* | _Final_
|
|
|*Date* | _2008-09-18_
|
|
|*Proposed by* | ct
|
|
|====================================
|
|
|
|
Interface Namespaces
|
|
--------------------
|
|
Interfaces and their implementations (plugins) need unique identifiers. We
|
|
describe here what schemes shall be used to ensure this.
|
|
|
|
Description
|
|
~~~~~~~~~~~
|
|
What are the goals?
|
|
|
|
* We need unique identifiers.
|
|
* We do not require anyone to register with us, this shall be a free system.
|
|
* There are two kinds, one bound to persons and one to projects as whole.
|
|
* Uniqueness, not identity is the goal, plugins could even be provided
|
|
anonymously.
|
|
* This is the lowest level interface stuff, usually you'll deal with a
|
|
high-level descriptor interface which provides much better (human readable)
|
|
meta information about a plugin.
|
|
* The names should follow C identifier rules and either not to hard to decipher
|
|
for a human or completely abstracted into a numeric ID like GPG id or UUID
|
|
* Conclusion followed some discussion on IRC and in the
|
|
https://lists.lumiera.org/pipermail/lumiera/2008-September/000054.html[Mailinglist(2008-09)]
|
|
|
|
|
|
First part: unique prefix
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Domain names and emails names encoding
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
Domain names in lowercase, dots and special chars removed, first char must be a
|
|
alphanumeric character (if it is numeric, just write it out):
|
|
|
|
------------------------------------------------------------
|
|
lumiera.org -> lumieraorg
|
|
Gmail.COM -> gmailcom
|
|
99foo-bar.baz.net -> ninetyninefoobarbaznet
|
|
------------------------------------------------------------
|
|
|
|
These are used when the provider is a project and not an individual person.
|
|
|
|
If the provider of a interface is a individual person then he encodes his email
|
|
address in a similar way The @ sign is encoded as uppercase `"AT"`:
|
|
|
|
|
|
------------------------------------------------------------
|
|
7of9@star-trek.net -> sevenofnineATstartreknet
|
|
------------------------------------------------------------
|
|
|
|
Abstract identifiers
|
|
^^^^^^^^^^^^^^^^^^^^
|
|
|
|
As alternative method one can use his GPG (or PGP) key ids or full
|
|
fingerprints. These are encoded as uppercase `"PGP"` or `"GPG"` followed with a
|
|
sequence of hex digits (both upper and lower case allowed):
|
|
|
|
|
|
------------------------------------------------------------
|
|
GPGAC4F4FF4
|
|
PGP09FF1387811ADFD4AE84310960DEA1B8AC4F4FF4
|
|
------------------------------------------------------------
|
|
|
|
Next completely random identifiers (UUIDs) are used by prefixing them with
|
|
uppercase `"UID"` followed by some alphanumeric characters (no underline), no
|
|
encoding is specified but must conform to be a C identifier, shall give a
|
|
entropy of 128 bits:
|
|
|
|
------------------------------------------------------------
|
|
UIDd557753400ad4ac6912773b1deb4d99d
|
|
------------------------------------------------------------
|
|
|
|
.Remarks
|
|
This are now quite a lot more or less unique encoding, notably we
|
|
could allow them all, they do not clash with each other. They would be parseable
|
|
if needed, but we never ever need to parse them, they are just taken as whole
|
|
and have no other meaning then being unique.
|
|
|
|
|
|
Following Parts: hierarchic namespace
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
Lumiera itself will use some hierarchical naming scheme for it interface
|
|
declarations and implementations. The details will be layed out next,
|
|
generally thinks look like:
|
|
|
|
------------------------------------------------------------
|
|
lumieraorg_backend_frameprovider
|
|
lumieraorg_plugin_video
|
|
------------------------------------------------------------
|
|
|
|
it is suggested that anyone providing plugins for Lumiera follows this and
|
|
extends it with his own identifier:
|
|
|
|
for example `joecoder@freevideo.org` writes a »ultrablur« then its identifier
|
|
would look like:
|
|
|
|
------------------------------------------------------------
|
|
joecoderATfreevideoorg_plugin_video_ultrablur
|
|
------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
Tasks
|
|
~~~~~
|
|
The above described scheme will be implemented and used by _cehteh_.
|
|
|
|
|
|
|
|
|
|
Rationale
|
|
~~~~~~~~~
|
|
I believe that writing plugins for Lumiera shall be simple. We do not want some
|
|
central registry or management. Anyone shall be able to just start to write
|
|
plugins. But that puts some responsibility on the namespace so that all plugins
|
|
can coexist and their names don't clash. The above describes a very simple and
|
|
flexible naming system which anyone can follow. It produces names which should
|
|
be sufficiently unique for practical purposes. It leaves alternatives for
|
|
providing plugins as institution, individual or even anonymously.
|
|
|
|
|
|
Conclusion
|
|
----------
|
|
Accepted by the
|
|
link:{ldoc}/devel/meeting_summary/2008-10-10.html#_interface_naming_convention[October.2008 developer meeting]
|
|
|
|
|
|
Addendum: Internal Interfaces
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Interfaces which are internal and not meant for public use have 2 underscores
|
|
after the prefix (eg: `lumieraorg__` ). These interfaces must not be used by
|
|
third party plugins, they are subject of unannounced changes or removal and
|
|
make no guarantee about backwards compatibility. When we spot someone using
|
|
this interfaces we will *break this plugin* intentionally!
|
|
|
|
ct:: '2008-10-24T03:43:43Z'
|
|
|
|
''''
|
|
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|