From 9e3ce2a297091f0ad16b2486476fce9004b43e92 Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 17:00:09 +0100 Subject: Rewrite section on crate types Signed-off-by: Matthias Beyer --- doc/src/01010-architecture.md | 59 ++++++++++++++++++++++--------------------- 1 file changed, 30 insertions(+), 29 deletions(-) diff --git a/doc/src/01010-architecture.md b/doc/src/01010-architecture.md index f3d98a9b..cc00f093 100644 --- a/doc/src/01010-architecture.md +++ b/doc/src/01010-architecture.md @@ -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: -* 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). -* 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 -domain, for example "libimagtodo" provides functionality to track todos. +## Crate types -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. +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 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. + +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 -- cgit v1.2.3