• oruga server
• dbhandled
• indexeador
• mpd

Todos los plugins se encuentran en la carpeta ./lib/. Cada plugin debe llamarse oruga_<nombre plugin>, donde es el nombre que se le quiera poner. Los archivos basicos que un plugin debe tener son:

• binario: Ejecutable del plugin
• <plugin>.js: Es el vinculo entre el plugin y Oruga. El nombre puede ser cualquiera (hasta la extension .js es opciona), pero tiene que ser el mismo que se defina en la seccion main del package.json.
• package.json: Ver package.json

Ejemplo de estructura de plugin:

lib/
└── oruga_dummy
    ├── dummy
    ├── dummy.js
    └── package.json

• dummy: es un archivo ejecutable (con permisos de ejecucion).
• dummy.js es lo que hara interactuar con Oruga (ver mas abajo).

Todos los plugins deben tener un archivo que hara que Oruga los reconozca como plugins, ademas de hacer que pueda interactuar con ellos. El archivo debe ser el siguiente:

var PluginManager = require('oruga_server').PluginManager,
	util = require('util');

function dummy(args, config) {
	var defArgs = [
		'-o0',
		'-i0',
		'-e0',
		__dirname+'/dummy'
	],
		defConfig = {
			cwd: "/usr/bin"
		};

	//PluginManager.call(this, __dirname+'/dummy', newArgs, newConfig);
	PluginManager.call(this, "stdbuf" , this.extendArgs(defArgs, args), this.extendConfig(defConfig, config));
}

util.inherits(dummy, PluginManager);

module.exports = dummy;

Primero se importan las librerias necesarias. Se define una funcion, cuyo nombre puede ser cualquiera que reciba dos parametros args y config. En defArgs y defConfig se usaran para asignar valores por defecto de parametros de flags y config respectivamente. Config son configuraciones acerca el entorno de ejecucion del archivo binario, ahi se puede setear el cwd (current working directory) y las variables de enviroment (mas informacion en http://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options )

• cwd: String Current working directory of the child process
• env: Object Environment key-value pairs
• detached: Boolean The child will be a process group leader. (See below)
• uid: Number Sets the user identity of the process. (See setuid(2).)
• gid: Number Sets the group identity of the process. (See setgid(2).)

Por ultimo, se llama a PluginManager.call(this, <binario>, <argumentos>, newConfig);

• binario: String es el binario a ejecutar, se puede usar la variable __dirname, para tener el path absoluto de la carpeta del plugin
• argumentos: Array of String, todos los argumentos

Para que funcione correctamente el plugin, cada vez que escribe en stdout y stderr, el plugin debe flushear. Si el plugin no lo hace, se puede resolver ese problema usando el comando stdbuff (por eso el ejemplo tiene las dos formas). Ejemplo:

PluginManager.call(this, "stdbuf" , ['-o0', '-i0', '-e0', __dirname+'/dummy'], newConfig);

Si se usa este fix, el binario debe ser "stdbuf", y los primeros 3 argumentos deben obligatoriamente ser '-o0', '-i0', '-e0', el siguiente argumento sera el binario del plugin y despues se agregaran todos los parametros que reciba el plugin.

A los plugins se interactuara por stdin, stdout y stderr.

• stdin: se usara para que el plugin reciba los eventos.
• stdout: el plugin enviara la respuesta de los eventos.
• stderr: el plugin dara cualquier mensaje de log (informacion, error, etc).

Nunca un mensaje de log se tiene que enviar por stdin, este estara reservado para el intercambio de mensajes.

Los mensajes que los plugins recibiran tinen la siguiente estructura <id>:<evento>:<data>

Donde:

• es un identificador, puede ser un nro, una cadena de caracteres, etc
• es una cadena de caracteres, es el nombre del evento
• es una cadena de caracteres encodeada como cgi (urlencoded), con parametros.

El plugin siempre (por stdout) debera devolver JSONs:

{
  "id": codigo de peticion 
  "response": diccionario en json
  "error" : 0 sin error, distinto de 0 para error
  "error_text": Descripcion del error
}