Lumiera
The new emerging NLE for GNU/Linux

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 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 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 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 Lumiera Design Process overview