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

53
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 In this chapter the types of crates, architecture of an imag module
and the type structure are described. and the type structure are described.
## Crate types ## Crate types
There are different types of crates in the imag world. A crate is a rust There are different types of crates in the imag world:
project.
First of all, there are core crates. These crates provide the very core of imag * "core" crates:
and almost all other crates use them: * 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 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.
(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.
* libimagstore - The imag store is the abstraction over the filesystem. It These are all libraries. There are also binary crates in the imag project
provides primitives to get, write and manipulate store entries and their (though they are technically _also_ library crates):
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).
* 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 * "core" binary crates, which implement core functionality of imag, such as
extensional functionality for the types from libimagstore. For example, there is commandline interfaces for tagging, linking, ... entries as well as querying
"libimagentrylink" which provides functionality to link two entries in the them from the store and altering their data.
store. * "domain" binary crates, which implement a domain such as "todo" handling or
"calendar" handling.
The third kind of crate is the one that offers end-user functionality for a imag
domain, for example "libimagtodo" provides functionality to track todos.
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.
Besides these, there are some other utility crates.
## Architecture of an imag module ## Architecture of an imag module