🐛 Fix “Adventures with Eggie”
[rhynodge.git] / README.md
1 # Rhynodge
2
3 ## Description
4
5 Rhynodge is a tool that lets you periodically execute tasks that depend on certain conditions.
6
7 Its concept is quite similar to websites like ifttt (“if this then that”): you evaluate an input condition (e. g. data from a website, Facebook or Twitter posts, incoming emails, existence of a file), and if it evaluates to â€œyes” you execute a certain action.
8
9 ## Configuration
10
11 Rhynodge’s configuration uses JSON files (I tried using XML first but apparently polymorphic deserialization is something that is not easily done with XML parsers). The format of a ``Chain`` configuration is pretty straight-forward and can be seen in the example configuration files.
12
13 ## Running Rhynodge
14
15 Rhynodge uses Gradle as build and dependency management tool. After creating a â€œfat jar” (a JAR file containing all required dependencies), simply run the jar file with
16
17 > $ java -jar build/libs/rhynodge-all-*.jar
18
19 Rhynodge accepts the following options using environment variables:
20
21 - ``SMTP_HOSTNAME``: the hostname of the SMTP server, is used for error emails; default is â€œlocalhost”
22 - ``ERROR_EMAIL_SENDER``: the email address to use as sender for error emails
23 - ``ERROR_EMAIL_RECIPIENT``: the email address to send error emails to
24 - ``CHAIN_DIRECTORY``: directory to load chain configurations from; default is â€œchains”
25 - ``STATE_DIRECTORY``: directory to store states in; default is â€œstates”
26
27 Both chain and state directories need to be created before running Rhynodge.
28
29 Rhynodge also periodically scans the chains directory to find changed or new chain configuration files. New files will be added to the running instance, changed files will be reloaded, and removing files will remove the corresponding job from Rhynodge.
30
31 ## Internal Concepts
32
33 The core of Rhynodge comprises ``Reaction``s which in turn consist of ``Query``s, ``Filter``s, ``Merger``s, and ``Action``s.
34
35 ### Query
36
37 A query is a component that determines the state of a system: it can determine whether a file exists, or retrieves the latest 5 Twitter posts, or loads data from a website.
38
39 The result of a ``Query`` is a ``State``.
40
41 ### Filter
42
43 A filter is an optional component that turns a ``State`` into a different ``State``. It is used to process data and extract more useful information; e. g. a filter could take the raw data from a website and parse its HTML into a DOM tree, or a list of files could be filtered for CD images larger than 400 MiB.
44
45 The result of a ``Filter`` is a ``State``, again.
46
47 ### Merger
48
49 A merger merges two states into a new state; the new state is responsible for detecting whether a noteworthy change has occured.
50
51 The result of a ``Merger`` is — once again — a ``State``.
52
53 ### Watcher
54
55 A watcher combines a query, a list of filters, and a merger into a single unit which can be configured a lot easier than the separate components. For example, you could have a â€œTwitter” that finds new status updates for a username and that only needs to be configured with that username; the rest of the configuration is contained in the watcher.
56
57 A ``Watcher`` does not do any processing but instead offers a ``Query``, a list of ``Filter``s, and a ``Merger``.
58
59 ### Action
60
61 If a noteworthy change has been detected, the action is then executed. Again, an action can be almost anything: it can send an email, it can execute programs, print documents, initiate phone calls, take a picture from a webcam — anything you can program can be used an an action.