More User Friendly

[lukevers]

Right now when you want to run kittens there are a lot of things that need to happen. You need to clone the repo, install dependencies, compile, gulp, and fill out a configuration file. I think the configuration file should die, and all the configuration options should be kept in the database and be loaded into memory when Kittens starts running. When changes are made to an option that's in the database we'll update the database accordingly.

The following are changes I think should be made for Kittens to be more user friendly.

Flags

Right now instead of using flags we're using a configuration file, but some of the options in the configuration file could be switched to flags instead. The idea is to eventually run a binary and not care about a configuration file anywhere because a database (ref #45) will have everything else we need. These are the ones I'm thinking of from the configuration file that can be turned into flags:

# verbose output (default value => false)
debug

# interface for website to bind to (default value => 0.0.0.0)
interface

# port for website to bind to (default value => 3000)
port

If any are not given then we give them default values. The only options that are not included currently would be MySQL (and other databases eventually) connection details anywhere. Should there be flags for that, too? I'm not sure if this is too much:

kittens --port=3000 --interface=0.0.0.0 --debug=true --database-host=localhost --database-port=3360 --database-name=kittens --database-username=root --database-password=root

I think it's a bit too much.

Database

Using MySQL as our primary database (and possibly supporting others like SQLite/PostgreSQL/etc) would remove a lot of other information from the configuration file. The following are tables that should be added:

Users

By adding a users table we can have multiple users, and properly store usernames/hashed passwords. Here's an idea of what columns the users table should have:

# primary key, auto incrementing
id

# varchar
username

# varchar
password

# timestamp
created_at

# timestamp
updated_at

Servers

Each server will have a similar structure to what is currently in the configuration file:

{
    "Nick": "kittens",
    "RealName": "Kittens IRC Bot",
    "Host": "kittens",
    "ServerName": "hypeirc",
    "Network": "irc.appno.de",
    "Port": 6667,
    "SSL": false,
    "Password": "",
    "Enabled": true,
    "Connected": false,
    "Channels": [
        {
            "Name": "#lukevers"
        },
        {
            "Name": "#go-nuts"
        }
    ]
}

but with a few differences. There will also be a user_id column which contains a foreign key that links to the user that owns this server. Instead of having an array of channels like we currently do we'll have nothing directly in this table. Each server will be linked from each channel in the channels table as a foreign key as the owner of that channel. Here's an idea of what columns the server table should have:

# primary key, auto incrementing
id

# varchar
nick

# varchar
real_name

# varchar
host

# varchar
server_name

# varchar
network

# integer
port

# bit
ssl

# varchar
password

# bit
enabled

# foreign key (user_id) references user(id)
user_id

# timestamp
created_at

# timestamp
updated_at

Connected also won't be in there because that is just a field that would be in memory. Actually it really shouldn't even be in the configuration file as it is right now.

Channels

Channels in the configuration file currently only has the name of the channel, so there's not much to go by from there. It's basically the same as the others in structure. Each channel has a server_id that is referenced to an id at the servers table. The server_id holds the server own of that particular channel. Here's an idea of what columns the channels table should have:

# primary key, auto incrementing
id

# varchar
channel

# foreign key (server_id) references server(id)
server_id

# timestamp
created_at

# timestamp
updated_at

[lukevers]

I've been thinking about how I want to completely remove all configuration files, but I just realized that I'm going to have to keep the resource files somewhere, so there's going to have to be a folder somewhere on the filesystem.

Environment variables are also an idea.

[lukevers]

go-bindata looks like it can embed resources into the binary by converting them into go files.