rattail/docs/glossary.rst
2020-02-23 19:02:20 -06:00

110 lines
4.8 KiB
ReStructuredText

.. _glossary:
Glossary
========
.. glossary::
:sorted:
app
As the term is used within Rattail Project documentation, this usually
refers to a custom software application, built using Rattail, which runs
on a server somewhere. Such an app may often be referred to with the name
:term:`Poser`, within the docs. An app may or may not be a :term:`web
app` for instance. Of course, "app" may also refer to *any* software
application.
web app
An :term:`app` which runs in a web browser, from the user's perspective.
app node
A specific instance of an :term:`app` which is part of a broader
(i.e. multi-node) :term:`system`.
system
This is mostly used generically, to represent various software
applications and/or devices etc. with which the :term:`app` must interact.
However sometimes the app itself may be referred to as a system, for
instance.
Poser
The "stand-in" name for a custom :term:`app` built using Rattail. No
actual app should ever be named Poser! When you see the name Poser, you
should mentally and literally replace it with whatever *other* name you
chose to give your app.
batch
Can generally be thought of as a temporary or "workspace" table, with data
which came from some source or other, and which the user may review and/or
manipulate, before ultimately "executing" it, which in turn will update
data within various systems, as appropriate. Note that the term "batch"
primarily refers to the data itself, or the model instance representing
it; see :term:`batch handler` for the logic part.
.. seealso::
:ref:`batches`
batch handler
Class or instance thereof, responsible for the "handling" logic for a
certain type of :term:`batch`. Generally each type of batch will have at
least one "default" handler available, though more are possible. The
batch handler knows how to populate, refresh and execute batches.
handler
Broadly defined, this refers to an abstraction layer which is meant to
allow for easier customization etc. within the code. The "handler"
concept allows business rules and/or other logic to be defined in a way
which transcends the app somewhat, but may still be driven by the app.
There are a number of "types" of handlers, e.g. :term:`batch handler` and
:term:`import handler` to name just a couple.
importer
Class or instance thereof, which contains logic for the import/export of
data for *one specific model*, from one system to another. Note the
difference between an importer and an :term:`import handler`. Whereas the
handler is responsible for the overall "transaction" between the two
systems, the importer is responsible only for a single table,
conceptually. In casual discussion, the term "importer" may sometimes be
thrown around a bit more loosely, and e.g. refer to the system-level
processes. But within the code proper, the term "importer" always will
imply a particular data model association.
.. seealso::
:ref:`importers`
import handler
Class or instance thereof, responsible for the "handling" logic for an
overall import/export from one system to another. Primarily this is
concerned with the "transaction" (e.g. database connections) and
rollback/commit for the systems involved, where applicable. Each handler
will contain at least one :term:`importer` although most have more.
daemon
A software :term:`app` or part thereof, which runs continually in the
background. Examples are :term:`datasync` and a :term:`web app`.
datasync
Refers to a particular :term:`daemon` whose responsibility is to "watch"
various systems for data changes, and when any are found, cause various
other systems to "consume" those changes. This is a configurable,
multi-threaded app which spawns a separate thread for each :term:`datasync
watcher`, as well as a separate thread for each :term:`datasync consumer`
(per watcher).
datasync watcher
Class or instance thereof, responsible for "watching" a particular system
for data changes, within the :term:`datasync` daemon. May also refer to
the specific thread spawned by the daemon to run the watcher logic.
Changes found by the watcher are then processed by at least one
:term:`datasync consumer`.
datasync consumer
Class or instance thereof, responsible for "consuming" changes from a
"watched" system within the :term:`datasync` daemon. Any change coming
from a :term:`datasync watcher` is (potentially) then consumed by one or
more other systems; each of which will use a separate consumer. May also
refer to the specific thread spawned by the daemon to run the consumer
logic.