From 1dc0ed0180184b2d2cf16b3fc5dfa1835d316199 Mon Sep 17 00:00:00 2001 From: Kern Sibbald Date: Tue, 8 Nov 2011 16:13:16 +0100 Subject: [PATCH] Spell check pluginAPI --- docs/manuals/en/developers/pluginAPI.tex | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/docs/manuals/en/developers/pluginAPI.tex b/docs/manuals/en/developers/pluginAPI.tex index 4856a5dd..386aad18 100644 --- a/docs/manuals/en/developers/pluginAPI.tex +++ b/docs/manuals/en/developers/pluginAPI.tex @@ -16,7 +16,7 @@ similar to how a {\bf RunScript} works, and the events are very similar. Once the plugin gets control, it can interact with Bacula by getting and setting Bacula variables. In this way, it behaves much like a RunScript. Currently very few Bacula variables are defined, but they will be implemented as the need -arrises, and it is very extensible. +arises, and it is very extensible. We plan to have plugins register to receive events that they normally would not receive, such as an event for each file examined for backup or restore. @@ -75,7 +75,7 @@ bRC unloadPlugin() both these external entry points to the shared object are defined as C entry points to avoid name mangling complications with C++. However, the shared -object can actually be written in any language (preferrably C or C++) providing +object can actually be written in any language (preferably C or C++) providing that it follows C language calling conventions. The definitions for {\bf bRC} and the arguments are {\bf @@ -94,7 +94,7 @@ files: Aside from the {\bf bc\_types.h} and {\bf confit.h} headers, the plugin definition uses the minimum code from Bacula. The bc\_types.h file is required -to ensure that the data type defintions in arguments correspond to the Bacula +to ensure that the data type definitions in arguments correspond to the Bacula core code. The return codes are defined as: @@ -299,13 +299,13 @@ loadPlugin() externally defined entry point. (malloc the memory) and store a pointer to its private working storage in the {\bf pContext} variable. Note: since Bacula is a multi-threaded program, you must not - keep any variable data in your plugin unless it is truely meant + keep any variable data in your plugin unless it is truly meant to apply globally to the whole plugin. In addition, you must be aware that except the first and last call to the plugin (loadPlugin and unloadPlugin) all the other calls will be made by threads that correspond to a Bacula job. The bpContext that will be passed for each thread will remain the - same throughout the Job thus you can keep your privat Job specific + same throughout the Job thus you can keep your private Job specific data in it ({\bf bContext}). \begin{verbatim} @@ -868,4 +868,3 @@ a real plugin, which is still rather simple and small. When actually writing your own plugin, you may use the example-plugin-fd.c code as a template for your code. - -- 2.39.5