Options: migrated server core to new option parser

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,