Adds an r2d2 database connection pool to the backend type. This makes
it possible for separate FSMs to run at the same time through the same
backend, by retrieving separate connections.
Introduces error variants for external crate errors and internal
errors.
Additional context can be provided at sites where errors occur using a
simple `.context()` call.
Implements the new backend trait for the FinitoPostgres type which
now represents instances of the Postgres backend.
This refactoring is not yet fully complete, as some restructuring of
the code is in order.
First version of a trait to abstract over backend implementations.
Currently the different backends still have a bit of specific
behaviour, but it should be possible to boil this down to a single
trait.
The primary question that is still open is how to best deal with the
interpretation of actions, as it is sort of up to the backend to
decide how to do that.
Changes the implementation of action execution to deal with the
returned associated errors.
The only sensible constraint on those errors that I could think of for
now is `Debug`, meaning that errors are now persisted as debug
messages.
This is not as nice to work with for a future implementation of
retryable actions as the equivalent in Haskell, but maybe an idea
shows up underway. The main issue is that most of the common error
types will not be implementing Serde traits, so serialization to/from
the same error type is difficult.
Adding an implementation constraint for JSON serialisation on error
types (i.e. `S::Error: Serialize + Deserialize`) would probably cause
headaches for users, especially if they are trying to use an
out-of-the-box error type or an error type wrapping foreign errors.
Det ska'kke være lett ...
Implements the associated error type for the FSM trait as
failure::Error. This makes it possible to fail gracefully in all
actions, for example in the updated definition of the `NotifyIRC`
action which now appends to a file.
Implements a simple model for executing actions which will run them in
sequence, synchronously, after advancing an FSM and committing the
initial transaction.
Note that multiple things are not yet taken into account:
* Error handling of actions (they can not currently fail)
* Retrying of actions
* Concurrency model
I started out by implementing the concurrency model similarly to the
green-threading method used in Hamingja (but using OS threads), but
slowly noticed that it may not be the best way to do that. It needs a
little bit of discussion.
Either way for most actions this method is fast enough to work for
implementing things on top of Finito's model.
Adds a test for the two most important functions in Finito's
PostgreSQL backend.
These actually require a local Postgres database to be available when
running. Currently the connection details are hardcoded in the test.
Adds the initial finito-postgres crate with type definitions for the
tables and initial functions to interact with persisted FSMs.
This is far from feature complete at this commit.
Checks in my classic, lockable door example implemented in Finito.
This does not yet contain the documentation of the door in the Haskell
version of Finito.
The implementation of this library is closely modeled after the core
abstraction in the Haskell library. This does not at all concern
itself with persistence, interpretation of effects and so on.
