1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
|
first create a configuration file, say config.json, that looks like follows:
{
"nick": "somenick",
"useNickServ": false
}
or, if the nick is registered with NickServ, then:
{
"nick": "somenick",
"pass": "somepass"
}
then enter the Nix shell for development:
cabal2nix . > default.nix && nix-shell -I stockholm=~/stockholm
and run the REPL:
build
run config.json
or, interactively:
ghci -isrc -Wall src/main.hs
withArgs ["config.json"] main
:r
# HTTP API
Reaktor can provide an HTTP API so external applications can control
its behavior. At the moment this is restricted to send PRIVMSGs to
registered channels.
## Enable the HTTP API
To enable the HTTP API, a listening address has to be configured.
This address can be a TCP port, specified like follows:
{
"API": {
"listen": "inet://127.0.0.1:7777"
}
}
or it can be an Unix domain socket, specified like follows:
{
"API": {
"listen": "unix:/path/to/reaktor.sock"
}
}
## Example usage of the HTTP API
Let's say your reaktor instance has been configured to listen to
inet://localhost:7777, and the register plugin has been configured
to join #somechannel. Then it is possible to send a PRIVMSG to
this channel using e.g. following command:
curl -fsSv http://localhost:7777/ \
-H content-type:application/json \
-d "$(jq -n '{command:"PRIVMSG",params:["#somechannel","derp!"]}')"
And similarly if unix:/path/to/reaktor.sock has been used instead:
curl -fsSv --unix-socket /path/to/reaktor.sock http://dontcare/ \
-H content-type:application/json \
-d "$(jq -n '{command:"PRIVMSG",params:["#somechannel","derp!"]}')"
|
