41 lines
1.5 KiB
Text
41 lines
1.5 KiB
Text
-----------------------------------
|
|
output API
|
|
-----------------------------------
|
|
|
|
The data we handle and output needs to be taken care of. We don't want to put
|
|
any limitation for this within the core so we have designed a output API which
|
|
allows us and others to easily develop "output drivers" which handles the data
|
|
processing.
|
|
|
|
The output drivers have complete access to the configuration file to allow them
|
|
a way to get user defined input. Eg. database access information.
|
|
|
|
!NOTE! functions that returns and integer always has the following specification:
|
|
|
|
zero if everything went well and a non zero value that indicates an error
|
|
that later can be identified by the output_error() function.
|
|
|
|
-- functions
|
|
|
|
output_init():
|
|
|
|
This function is called on startup and allows the output driver to initialize
|
|
stuff that is needed later on. Eg. loading configuration options and/or connecting
|
|
to the database.
|
|
|
|
output_process():
|
|
|
|
Is called every time a new event is triggered. The event is passed to the function
|
|
and after that it is up to the driver to do some magic. NOTE that you are not supposed to free the memory
|
|
for the basic reason that you don't know now how it was allocated and even if you knew, it may change and
|
|
we are stuck with inconsistent modules.
|
|
|
|
output_error():
|
|
|
|
Converts error numbers to actual error strings. This function is used by the core
|
|
to display error messages from the output driver.
|
|
|
|
output_exit():
|
|
|
|
Called when the program is exiting (For whatever reason). It allows you to clean up
|
|
your mess.
|