continuous-integration/drone/push Build is passingDetails
continuous-integration/drone/pr Build is passingDetails
- Adds migrations for the necessary tables.
- Implements the user variables database functions.
- Adds sqlx metadata for 'offline' use so we can build without a database.
continuous-integration/drone/pr Build is passingDetails
continuous-integration/drone/push Build is passingDetails
Instead of relying on all parts of the application to construct both
HTML and plain-text responses, we now construct only HTML responses,
and convert the HTML to plain text right before sending the message to
Matrix.
This is a first iteration, because the plain text has a few extra
newlines than it should, created by use of nested <p> tags.
continuous-integration/drone/push Build is passingDetails
This upgrade introduces a handful of breaking changes in the Rust
Matrix SDK.
- Some types have disappeared and changed name.
- Some functions are no longer async.
- Room display name now has a Result type instead of just returning
the value.
- Client state store has breaking changes (not really a big deal).
This required introduction of a new type to store room information
that we are interested in on the context struct. This new RoomContext
is required mostly due to unit tests, because it is no longer possible
to instantiate the Room type in the Matrix SDK.
The database API for user variables has changed somewhat again, this
time closer to the proper vision. There are now two separate sled
Trees in the Variables struct, one for user-defined variables, and one
for counts. Keys have been changed to be username-first, then room ID.
The signatures of the functions now also use a strongly-typed struct,
UserAndRoom.
As part of this, the Context object now once again avoids allocating
new strings.
Other random changes included here:
- Remove tempfile crate in favor of sled temporary db config.
- Add bincode crate in anticipation of future (de)serializing.
This is a bit of a large commit that adds basic database migration
support. It also alters the way user variables are stored in a way
requiring manual migration of existing data. The first automated
migration adds variable count in a new place.
This commit introduces the Sled embedded key-value store for keeping
track of user variables on a per-room basis. Extensive changes were
made to the command module to separate concerns and also pass the
database "connection" down the line.
- A new "Context" object was created to hold information and state
needed for command execution (namely the database).
- Database is very simple for now, storing only user variables.
Refactoring later for storing more complicated types.
- State actor moved into Actors struct, in preparation for either
more actors, or ripping the whole thing out entirely.
- Other modules are also more properly separated, notably
the config module is entirely self-contained.
Only expose config settings via methods on the Config struct. This
allows default value handling to live entirely inside the config code,
solves various borrowing issues with the "create default bot config
value" solution, and allows us to avoid cloning the bot config values.
The downside is that the config must now be in an Arc since its
ownership is shared in multiple places and the matrix SDK requires
thread-safe types (perhaps in the future we re-compose traits and use
Rc for config instead).
This commit also further cleans up and splits up the bot code for the
matrix connection, notably making the main message event handler
smaller by splitting out the "should we process the message" checks
into a separate function.
Instead of using an Arc Mutex for state management embedded directly
into the bot, utilize actor pattern, with the idea that this will be
much more useful than simply logging a message once in the future.
This also refactors the bot code so that instead of a single run_bot
function, the DiceBot struct now has a run() method attached to it.
This also necessitated changes and cleanup to the dicebot main, which
is for the better anyhow.
The error and config types are also now in their own files, and
implemented for more in-depth use cases.
This makes the oldest message age setting optional, in additon to the
entire bot config (for now). If the oldest message age is not
specified (or if the entire bot config is missing), it will default to
15 minutes.
This gives us many things for free, like automated state management,
no need to declare special API structs and use HTTP requests directly,
and most importantly: ENCRYPTION!
projectmoon
Taylor C. Richberger