[srvx-devel] srvx-2.0 draft architecture document

[Entrope <en...@us...>]

Again, comments.  This only discusses the lower levels, and doesn't
specify how services interact with each other.

(This could probably be rolled into doxygen-compatible docs, but I
haven't looked up how to import a graph file like framework.dot.)

Entrope

======================
= srvx 2.x Framework =
======================

This document describes the general architecture and details the lower
levels of the srvx 2.x framework.  It is intended as both a design
spec and a "getting started" guide for new developers.

A rough diagram of the layering is available in framework.dot. (To
convert it to GIF, run "dot -Tgif -o framework.gif framework.dot".)
Each node in that graph has its own section in this file.

=================
= framework.dot =
=================

digraph srvx {
    label="srvx component framework";

    svc_mods    [label="service modules"];
    svc_core    [label="services core"];
    irc_core    [label="IRC core"];
    logging     [label="logging"];
    db_virt     [label="DB virtualizer"];
    ioset       [label="ioset I/O code"];
    formatters  [label="string formatters"];
    db_libs     [label="database libs"];
    os_apis     [label="C++ standard library,\nBerkeley sockets,\nother system APIs"];

    svc_mods -> { svc_core irc_core logging ioset db_virt };
    svc_core -> { irc_core formatters };
    irc_core -> { ioset };
    logging -> { formatters db_libs os_apis };
    db_virt -> { db_libs os_apis };
    ioset -> { os_apis };
    db_libs -> { os_apis };
}

========================
= HIGH LEVEL OVERVIEWS =
========================

C++ standard library, Berkeley sockets, other system APIs
---------------------------------------------------------

These are system APIs that srvx does not implement, but merely runs on
top of.

ioset I/O code
--------------

An "ioset" is a managed set of sockets.  The manager can: initiate new
outbound connections, set up new listening sockets, close sockets
(whether connected or listening), and check for read and/or write
activity on registered sockets (with a specified inactivity timeout).

The operations on an ioset are high level, so that it may be
implemented with either a polling API or completion port API, without
overly impacting its users.

See: srvx::ioset, srvx::socket, srvx::iobuf classes

string formatters
-----------------

Utilities to format strings and provide internationalization support.

See: srvx::format class (will be heavily revised for I18N)

database libs
-------------

This represents supported third-party (or recdb) database libraries;
for example, libpqxx or the C++ bindings for the Sleepycat Berkeley
DB.

See: third party documentation for them

DB virtualizer
--------------

This component acts as an adapter between internal database
representation and the external APIs.  It also provides helper
utilities such as a dirty object cache.

See: (not yet written; probably srvx::database class)

logging
-------

Directs log events to appropriate consumers.  Depending on
configuration, it might send command logs to a SQL database, error
notices to an IRC channel, and other messages to a text file.

See: srvx::logger, srvx::log class, srvx::log_store classes

IRC core
--------

This provides the API and core of IRC support in a protocol-agnostic
way.  It interfaces between the per-protocol support code and the
individual services and service modules.

See: srvx::irc::protocol class

services core
-------------

Provides helper utilities and code common to many service modules.

See: (not yet written; probably srvx::service class)

service modules
---------------

Each module implements a family of commands; for example, userlist
maintenance, channel control, proxy checking, etc.

See: (not yet written)