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 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
and almost all other crates use them:
* "core" crates:
* libimagstore - The imag store is the abstraction over the filesystem. It * libimagstore - The imag store is the abstraction over the filesystem. It
provides primitives to get, write and manipulate store entries and their provides primitives to get, write and manipulate store entries and their
header information. header information.
* libimagrt - The runtime library, which provides functionality to create a * libimagrt - The runtime library, which provides default argument parser
store object from libimagstore, helps with configurarion loading and setup, interfacing with STDIN/STDOUT, configuration loading and parsing.
commandline argument handling (through the external "clap" crate). Simply put: It provides the runtime for a imag commandline application.
* libimagerror - Error handling library for handling errors the imag way. Used * libimagerror - Error handling library for handling errors the imag way. Used
in all other crates, even the store itself. It also offers functionality to 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. log and trace errors as well as exiting the application, if necessary.
* libimagutil - Utilities. (Note: This library might be removed in the future.)
* "entry" crates:
The next type of imag crates are entry extension libraries. Those provide "Entry" crates provide extensional functionality for the types from
extensional functionality for the types from libimagstore. For example, there is libimagstore. For example, there is "libimagentrylink" which provides
"libimagentrylink" which provides functionality to link two entries in the functionality to link two entries in the store.
store. * "domain" crates offer end-user functionality for a imag
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. 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 These are all libraries. There are also binary crates in the imag project
interface. These are the kind of crates that are not library crates, but (though they are technically _also_ library crates):
binaries.
* "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 ## Architecture of an imag module