[[TOC]]

= Introduction =
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.

The plugin loader is build on top of the dynamic loader abstraction and can be used at different levels of abstraction.

= Main layers =
The plugin API consists of 3 main layers: the Dynamic Loader, the Llugin Loader and the Plugin Container.

== The Dynamic Loader ==
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.

== The Plugin Loader ==
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.

== The Plugin Container ==
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.

= Common Services =
The plugin API provides some common services as found in a lot application specific plugin interfaces.

== AppSched ==
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.

AppSched works by registering callbacks for special events. The following events are defined:

||= Event =||= Description =||
||INIT     ||This is called when the application wants to start the plugin. Normally you run code to open IO or build data structures here. ||
||FREE     ||This is called when the plugin is no longer used (on unload). You normally close all your IO and free memory you allocated here. ||
||UPDATE   ||This is called when you should do a main loop iteration. You can check your IO here and do your work. This function must not block. This is normally called once per main loop cycle of the host application. ||
||TICK     ||This is a an asynchronous event. Some applications use it when doing some longer work. It can be used to sync your IO like answer re-draw requests from the X server. You must not block in this function. ||
||WAIT     ||This is to ask the plugin to block and wait for new work to be done. This is normally used to wait for new IO events such as data from clients or X11 events. This can block for a long time. UPDATE is called soon after this returned so you do not need to call it from here. ||

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.

== Context separation ==
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.

The following is currently supported context separation:
* libroar's error state
* system's error state
* global data of the plugin
* global notify core

= List of Subtopics =

[[TitleIndex(libroar/plugins/)]]