Changes between Version 5 and Version 6 of libroar/plugins
- Timestamp:
- 03/20/12 14:37:18 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
libroar/plugins
v5 v6 1 1 [[TOC]] 2 2 3 = Introduction=3 == Introduction == 4 4 libroar contains a plugin loader API. It can be used by any application to load plugins. It is not specific to audio or any of the RoarAudio software packages. It is designed universally and handles tasks common to all plugin interfaces such as loading of needed files, handling meta data (such as plugin name, author and description) as well as passing data between the plugin and the host application. 5 5 6 6 The plugin loader is build on top of the dynamic loader abstraction and can be used at different levels of abstraction. 7 7 8 = Main layers=8 == Main layers )== 9 9 The plugin API consists of 3 main layers: the Dynamic Loader, the Llugin Loader and the Plugin Container. 10 10 11 == The Dynamic Loader==11 === The Dynamic Loader === 12 12 The Dynamic Loader is a abstraction of the system's dynamic loader. It is abled to load all shared libraries and shared library formats as used by the system. It is designed similar to the POSIX dlopen() and friends. 13 13 14 == The Plugin Loader==14 === The Plugin Loader === 15 15 The Plugin Loader is build directly into the Dynamic Loader and can be activated by a single boolean setting (ra_init). If enabled it will try to find a plugin entry symbol and start loading the plugin. This includes setting up an new context for the plugin with global data and error states as well as registering all the services the plugin provides. This also checks if the plugin is actually be written for the host application so it can not crash later because of mismatching ABIs. 16 16 17 == The Plugin Container==17 === The Plugin Container === 18 18 The Plugin Container is a separate module. It can store multiple plugins at the same time and makes it easy for an application to handle them. A application using the container does not need to keep a list of plugins or send events to them individually but just pass the stuff to the container. 19 19 20 = Common Services=20 == Common Services == 21 21 The plugin API provides some common services as found in a lot application specific plugin interfaces. 22 22 23 == AppSched==23 === AppSched === 24 24 The AppSched is a way to allow the plugin to run event independed code. For example if the plugin copies data from one to another location AppSched is used to do that job. It is normally used to implement a main loop like structure. 25 25 … … 35 35 Every AppSched using application (every should in fact!) will send INIT, FREE and UPDATE. The usage of TICK and WAIT is optional by the application. 36 36 37 == Context separation==37 === Context separation === 38 38 The Plugin API supports context separation. This means that the plugin runs in it's own context and will not see the context of the host application or of other plugins. This also allows the same plugin to be loaded multiple times without them interacting. 39 39 … … 44 44 * global notify core 45 45 46 = List of Subtopics=46 == List of Subtopics == 47 47 48 48 [[TitleIndex(libroar/plugins/)]]
