Ichthyostega
051cb31e28
The RfC documents were written to complement discussions of the Lumiera developers; yet since the time where ''Ichthyo'' is working basically alone on the project, this kind of discussions have ceased. During the following years, some ideas promoted by the existing RfC documents became rather detached from the actual state of development in the code base. Many of the existing RfC documents require some commentary to place them into context, and some of the decisions taken in the early stage of the project should be **re-assessed**. This includes the decision to reject some proposals, which initially might have seemed desirable, yet could not be reconciled with the understanding of the matter and topic in question, as was gained through the ongoing analysis and development.
162 lines
5.9 KiB
Text
162 lines
5.9 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'
|
|
|
|
|
|
Clarification of relevance
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
As this RfC touches on the subject of Plug-ins, it should be stated very clearly
|
|
that Lumiera is **not based on a »Plugin Architecture«**. This Architecture Style
|
|
was indeed link:{rfc}/AllPluginInterfacesAreC.html[proposed and considered] during
|
|
the early stages of the project, but rejected later, based on the ensuing discussion
|
|
and experience with existing systems, as well as with our own implementation drafts
|
|
going into this direction.
|
|
|
|
Lumiera will use Plug-ins however, to add _optional capabilities._
|
|
And thus everything stated in this RfC regarding unique identifiers remains valid.
|
|
|
|
Ichthyostega:: '2025-09-20'
|
|
|
|
''''
|
|
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|