matthiasbeyer/imag
1
0
Fork 0
Code Releases Activity

Rewrite section on crate types

Browse source 
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This commit is contained in:
Matthias Beyer 2019-11-09 17:00:09 +01:00
parent a99c587d6c
commit 9e3ce2a297
1 changed files with 27 additions and 26 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

41
doc/src/01010-architecture.md
View file

@ -4,38 +4,39 @@ The imag codebase has a rather simple overall architecture.
In this chapter the types of crates, architecture of an imag module
and the type structure are described.
## Crate types
There are different types of crates in the imag world. A crate is a rust
project.
First of all, there are core crates. These crates provide the very core of imag
and almost all other crates use them:
There are different types of crates in the imag world:
* "core" crates:
* libimagstore - The imag store is the abstraction over the filesystem. It
provides primitives to get, write and manipulate store entries and their
header information.
* libimagrt - The runtime library, which provides functionality to create a
store object from libimagstore, helps with configurarion loading and
commandline argument handling (through the external "clap" crate).
* libimagrt - The runtime library, which provides default argument parser
setup, interfacing with STDIN/STDOUT, configuration loading and parsing.
Simply put: It provides the runtime for a imag commandline application.
* libimagerror - Error handling library for handling errors the imag way. Used
in all other crates, even the store itself. It also offers functionality to
log and trace errors as well as exiting the application, if necessary.
* libimagutil - Utilities.
The next type of imag crates are entry extension libraries. Those provide
extensional functionality for the types from libimagstore. For example, there is
"libimagentrylink" which provides functionality to link two entries in the
store.
The third kind of crate is the one that offers end-user functionality for a imag
(Note: This library might be removed in the future.)
* "entry" crates:
"Entry" crates provide extensional functionality for the types from
libimagstore. For example, there is "libimagentrylink" which provides
functionality to link two entries in the store.
* "domain" crates offer end-user functionality for a imag
domain, for example "libimagtodo" provides functionality to track todos.
* "etc"/"util" crates for simple utilities.
And last, but not least, the commandline frontend crates provide the user
interface. These are the kind of crates that are not library crates, but
binaries.
These are all libraries. There are also binary crates in the imag project
(though they are technically _also_ library crates):
* "core" binary crates, which implement core functionality of imag, such as
commandline interfaces for tagging, linking, ... entries as well as querying
them from the store and altering their data.
* "domain" binary crates, which implement a domain such as "todo" handling or
"calendar" handling.
Besides these, there are some other utility crates.
## Architecture of an imag module