Introduction to Add-On Modules

All requests sent to the Robin Hood server are handled by add-on modules. The modules are invoked based on the MIME type (real or virtual) of the requested resource. New features can be added to the server by installing new or replacing existing add-on modules. The server does not even need to be restarted; the modules are dynamically loaded and unloaded when items are added to or removed from the "robin_hood_modules" folder.

The rhdaemon maintains a roster of available add-ons. All valid add-ons in the "robin_hood_modules" folder are loaded when the server starts and this folder is monitored for changes while the server is running. If a new module is moved into this folder, it will be loaded and its features will be made available immediately. When a module is removed, its features will no longer be made available to new requests and it will be unloaded as soon as all active requests are done using it. You may disable features you do not wish to make available by removing the corresponding module.

Modules run in the same memory space as the rhdaemon. If a bug in a module causes a crash, the entire server will stop. It may be possible to remove the buggy module until the bug can fixed.

When a request is received by the rhdaemon, it asks the module roster to handle the request. First the roster will check to see if the resource exists. The search will proceed from the top down. For example, if a request for "/foo/bar/foobar.html" is made, it will first check for "/foo/bar/foobar.html", if it does not exist, it will check for "foo/bar", and finally "/foo." If it finds a resource, the MIME type of the resoure is obtained. The path of the resource is then checked against the list of virtual resources with the "real" tag set to "true." If any matches are found, the resource is given the virtual MIME type defined by the virtual resource. This is used only for determining which module to invoke, it does not change the returned resource type. If the resource was not found, the path is checked against all virtual resources with the "real" tag set to "false." If no virtual resources match, the roster generates a simple "404 Not Found" message for the client. If a resource was found (real or virtual), the roster will try to find a module to handle the MIME type (real or virtual) of the resource. It will ask each module if it can handle the specified MIME type and if the module can handle it, the module returns its priority. The priority is a number which is used to determine which module to invoke when more than one module can handle the MIME type. The module with the highest priority will be chosen and invoked. If no modules can handle the request, "501 Not Implemented" is returned by the roster.

BeOS is a registered trademark of Be Inc.