The aimy software's data flows through a heirarchy of objects that direct information to the top where it's processed. The top of the heirarchy is referred to as "the root object". It contains service items, and is itself contained by a Core object which is not part of this heirarchy but provides operational services to the root object.
The core.Object class implements basic
functionality necessary for operation within the
heirarchy of objects - often called the "root tree" -
that make up the aimy project software. This includes
logging, default event/command handling, dispatching
of commands, and (via it's superclass, core_basic)
linkage of objects in both the upward and downward
directions through the heirarchy.
The core.ORISC class implements sharing
of processor time for objects that each have a specific
task not necessarily directly related to each other.
ORISC is an acronym that stands for Open, Run, IO, Stop, and Close. I couldn't think of a better name. Sorry.
ORISC-based subclasses will typically implement open(), io(), and close() methods. The run(), stop(), and most other methods are pretty much "final" in that usually nothing more needs to be done there.
The core.Core class implements a base from
which the root object can operate. The point of it is
that the root object and it's tree of service objects
must be apart from the Core that implements the
coreload() method. Other than that, Core can safely be
ignored for the purposes of this document.
Core creates a root object from a configuration file or dict. It "opens" the root object and then loops, calling root's .io() method until the process is stopped.
The root object may be of any subclass of core.Object,
but typically will be a core.service.Service subclass,
since that's the class that implements containment of
child objects within the tree.
The default aimy configuration at my/config.json
creates a my.Bot object that is by default
a (mostly) empty Service. The my.__init__ package can be
edited to add features or customizations.
The my.Bot class is actually based on ai.Bot,
which over time will (again, hopefully) add functionality
related to Artificial Intelligence.
As it's a service, the root object can contain other service items to facilitate connections to the outside world. Each connection is maintained by an object stored within its tree of owned items.
Data received by service item connections is packaged as an EventView or CommandView (See util.event). Commands are sent to the root object's onCommand() method. Input data that are not commands are sent to the root's onEvent() method to be handled (or ignored) as the application sees fit.
The Core class is defined in the core/__init__.py file. The Service class, which default root object and all its items are based on, is defined in the core.service module's __init__.py file.
The connections shown to in this image are based on the Handler class, also defined in core.service.
Note that, with the exception of Core, the items in this image are not labeled with class names, but with item names as described in the default config file (like the one at my/config.json). The 'http' item is defined in the core.service.http module, but the 'admin' and 'public' items are both extensions of the core.service.Handler class, and the 'irc' item itself is a simple core.service.Client object.
Most of the items in this image (as described in configuration) are based on core.service.Service, and so make use of the same mechanism for storing sub-items. However, this is not mandatory - the irc service contains IRC "Connect" items instead of Service-based items.
Event and Command classes are defined in the util.event module. The dispatcher and Dispatch classes (which typically handle commands) are defined in the core.dispatch module.
