Architecture

This page currently (04-08-2019) reflects an idealised version of what architecture we are aiming for. It's meant as a development roadmap for the next few months.

The libreflip software stack is split into sans (the server software and utilities) and serif. This page will not talk about serif in detail; only that it exists and talks to sans via a RESTful API.

sans itself consists of a few components:

• sans-core is a collection of modules that drive the hardware. This includes the actual hardware processing and a camera abstraction module. Inside the core, there is sans-types which are shared types across all crates. This is split into it's own crate to get around the problem of cyclical dependencies in Rust.
• sans-server is the main binary which starts the HTTP interface (optionally) and has a main run-loop which handles commands and manages the hardware.
• sans-processing is a small module inside the server which delegates jobs to an external worker.
• sans-worker is the second binary in the sans ecosystem. It spawns worker threads, and schedules tasks across them. Work is sent from the processing module in the server, then handled by a worker thread, and their results sent back. Because sans-worker uses RPC, a worker doesn't have to reside on the same machine as the server.
• sans-ctrl is a commandline interface to interact with the server. This includes getting scanner status, the worker queue status and maybe even setup the machine to scan. Potentially every action taken via the web UI should also be possible via the CLI, which uses a similar RPC bridge as the workers.

insert architecture picture here

Current state

The description above is the "end goal" situation. Here's what's implemented (roughly):

• sans-core can initialise a hardware listener and capture images (in theory) - configuration is currently terrible and relies on hard-coded resolutions which, if not setup properly, will cause the whole stack to crash.
• sans-server is currently a REPL to send low-level commands to the hardware
• sans-processing has a trait to do scheduling, but should be re-written
• sans-worker doesn't really have much code in it (with both processing (which should maybe be renamed to sans-schedule?) and worker, there's a lot of work to be done on the RPC interface. Not entirely sure what's best to use. Maybe protobuf? Maybe something simple like message pack? Who knows)
• sans-ctrl (or sans-cli?) has some CLI options but doesn't actually do anything with them
• The HTTP interface in sans-server is mostly commented out and should be re-done in a better web framework that doesn't break every 5 seconds...