docs.roxen.comView this page in a printer friendly mode
DocsRoxenWebServer 5.4System Developer Manual PikeThe Roxen Module API
Copyright © 2018, Roxen Internet Software
Suggestions, comments & compliments
manuals@roxen.com
 DEMO  DOCS  PIKE
 COMMUNITY  DOWNLOAD
www.roxen.com

   

Introduction to Roxen Modules
The Module Type Calling Sequence
Constants Common to All Modules
Callback Methods Common to All Modules
API Methods Common to All Modules
Module Variables
Tag Modules
Location (Filesystem) Modules
File Extension Modules
Filter Modules
Authentication Modules
Logger Modules
First Modules
Last Modules
Provider Modules
Content Type Modules
Directory Listing Modules

Constants Common to All Modules

This page covers all constants that all module types may or are expected to provide with information about the module. (Be sure to see the sections on common callback methods and API methods too.)
string cvs_version;

This string (filtered to remove some ugly cvs id markup) shows up in the roxen administration interface when handling module parameters in developer mode (configured under "User Settings" below the Admin tab). It will also serve as the basis for extracting version information of the file in the inherit tree. Optional, but convenient, especially if you use cvs for version control of your code.

string module_name;

The name that will show up in the module listings when adding modules or viewing the modules of a virtual server. Keep it fairly informative and unique, since this is the only means for identification of your module in the most brief add module view mode.

int module_type;

Module type (see server/etc/include/module.h). May be bitwise ored (|) for hybrid modules. Hybrid modules must implement the required API functions for all of the module types they are hybrids of.

string module_doc;

The documentation string that will end up in the administration interface view of the module just below the module name. Also shows up in the more verbose add module views.

int module_unique;

0 to allow multiple instances of the module per virtual server, 1 to allow at most one.

int thread_safe;

Tell Roxen that this module is thread safe. That is, there is no request specific data in module global variables (such state is better put in the RequestID object, preferably in the id->misc mapping under some key unique to your module).

If your module is not thread safe, setting this flag to zero (0) or leaving it unset altogether will make roxen serialize accesses to your module. This will hurt performance on a busy server. A value of one (1) means your module is thread safe.