summaryrefslogtreecommitdiffstats
path: root/doc/development
diff options
context:
space:
mode:
Diffstat (limited to 'doc/development')
-rw-r--r--doc/development/core.txt25
1 files changed, 16 insertions, 9 deletions
diff --git a/doc/development/core.txt b/doc/development/core.txt
index 3953d3402..ecbcbebd3 100644
--- a/doc/development/core.txt
+++ b/doc/development/core.txt
@@ -10,8 +10,10 @@
Bcfg2 1.3 added a pluggable server core system so that the server core
itself can be easily swapped out to use different technologies. It
-currently ships with two backends: a builtin core written from scratch
-using the various server tools in the Python standard library; and an
+currently ships with several backends: a builtin core written from
+scratch using the various server tools in the Python standard library;
+a variant on the builtin core that uses Python 2.6's
+:mod:`multiprocessing` library to process requests in parallel; and an
experimental `CherryPy <http://www.cherrypy.org/>`_ based core. This
page documents the server core interface so that other cores can be
written to take advantage of other technologies, e.g., `Tornado
@@ -20,20 +22,25 @@ written to take advantage of other technologies, e.g., `Tornado
A core implementation needs to:
-* Override :func:`Bcfg2.Server.Core.BaseCore._daemonize` to handle
- daemonization, writing the PID file, and dropping privileges.
-* Override :func:`Bcfg2.Server.Core.BaseCore._run` to handle server
+* Override :func:`Bcfg2.Server.Core.Core._run` to handle server
startup.
-* Override :func:`Bcfg2.Server.Core.BaseCore._block` to run the
+* Override :func:`Bcfg2.Server.Core.Core._block` to run the
blocking server loop.
-* Call :func:`Bcfg2.Server.Core.BaseCore.shutdown` on orderly
+* Call :func:`Bcfg2.Server.Core.Core.shutdown` on orderly
shutdown.
+A core that wants to use the network (i.e., a core that isn't used
+entirely for introspection, as in :ref:`bcfg2-info
+<server-bcfg2-info>`, or other local tasks) should inherit from
+:class:`Bcfg2.Server.Core.NetworkCore`, and must also override
+:func:`Bcfg2.Server.Core.NetworkCore._daemonize` to handle daemonization,
+writing the PID file, and dropping privileges.
+
Nearly all XML-RPC handling is delegated entirely to the core
implementation. It needs to:
-* Call :func:`Bcfg2.Server.Core.BaseCore.authenticate` to authenticate
- clients.
+* Call :func:`Bcfg2.Server.Core.NetworkCore.authenticate` to
+ authenticate clients.
* Handle :exc:`xmlrpclib.Fault` exceptions raised by the exposed
XML-RPC methods as appropriate.
* Dispatch XML-RPC method invocations to the appropriate method,