From 33e53dca6dbcd27e1b905583b2c113e518eba275 Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 16:50:29 +0100 Subject: [PATCH 01/13] Remove untrue paragraph Signed-off-by: Matthias Beyer --- doc/src/09020-changelog.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/doc/src/09020-changelog.md b/doc/src/09020-changelog.md index 023086c4..c3299649 100644 --- a/doc/src/09020-changelog.md +++ b/doc/src/09020-changelog.md @@ -2,13 +2,6 @@ This section contains the changelog. -We try to include a changelog line in each pull request, to make sure the -changelog is up to date when releasing a new version of the codebase. -Make sure to append the new change to the list, do not prepend it. - -The "Major" section of each section includes huge changes in functionality and -interfaces (but not necessarily user-facing ones), whereas the "Minor" section -contains only small stuff. Some things, like typo fixes, version string updates and such are not stated in the changelog (though updating of dependencies is). Please note that we do not have a "Breaking changes" section as we are in From 0d27139cf7c8a3a301f5c80401a8eeee8bf50bdd Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 16:51:21 +0100 Subject: [PATCH 02/13] Remove trailing whitespace Signed-off-by: Matthias Beyer --- doc/src/01000-intro.md | 4 ++-- doc/src/03010-conventions.md | 4 ++-- doc/src/09010-contributing.md | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/src/01000-intro.md b/doc/src/01000-intro.md index ca645b53..a8f75cbd 100644 --- a/doc/src/01000-intro.md +++ b/doc/src/01000-intro.md @@ -1,7 +1,7 @@ # Introduction {#sec:introduction} This document is the user documentation for imag, the personal -information management suite for the commandline. +information management suite for the commandline. **Basically: This is Hobby stuff. Expect incompleteness, false statements and generally read with grain of salt.** @@ -74,7 +74,7 @@ The difference between imag and the mentioned projects is: querying. * zim is a wiki, which could be used for PIM but is not specialized for it. Recording habits might be possible, but not that simple as with imag - + imag is not there yet, though. Some parts can be used, though it is far away from being feature-complete. diff --git a/doc/src/03010-conventions.md b/doc/src/03010-conventions.md index 5e9ffe7e..77856353 100644 --- a/doc/src/03010-conventions.md +++ b/doc/src/03010-conventions.md @@ -47,7 +47,7 @@ Libraries which provide functionality for entries or the store but no domain-functionality should be named "libimagentrything" whereas "thing" stands for what the library provides. -All domain libraries should be prefixed with "libimag". +All domain libraries should be prefixed with "libimag". ### Library scope @@ -93,7 +93,7 @@ possible without a lot of effort, but still: more tests = better! The commandline tools are the CLI-frontends for their respective libraries. So `libimagdiary` has a CLI frontend `imag-diary`. -Those CLI frontends use functionality from `libimagrt` to build a +Those CLI frontends use functionality from `libimagrt` to build a commandline interface which is consistent with the rest of the ecosystem. Commandline applications use the runtime interfaces for receiving IDs from the diff --git a/doc/src/09010-contributing.md b/doc/src/09010-contributing.md index 1978cccc..a86ae2e9 100644 --- a/doc/src/09010-contributing.md +++ b/doc/src/09010-contributing.md @@ -51,7 +51,7 @@ All dependencies are installable with the nix package manager by using a ## Commit guidelines Make sure your patchset does not contain "Fixup" commits when publishing it, but feel -free to send "Fixup" commits in the review process. +free to send "Fixup" commits in the review process. If squashing fails I will come back to you. We do not follow some official Rust styleguide for our codebase, but we try to From 4b118a4fe126e28e5d066fb9e427309bb182deb9 Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 16:51:59 +0100 Subject: [PATCH 03/13] A reader should expect this to be outdated Signed-off-by: Matthias Beyer --- doc/src/01000-intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/src/01000-intro.md b/doc/src/01000-intro.md index a8f75cbd..3a991b82 100644 --- a/doc/src/01000-intro.md +++ b/doc/src/01000-intro.md @@ -3,8 +3,8 @@ This document is the user documentation for imag, the personal information management suite for the commandline. -**Basically: This is Hobby stuff. Expect incompleteness, false statements and -generally read with grain of salt.** +**Basically: This is Hobby stuff. Expect incompleteness, outdated documentation, +false statements and generally read with grain of salt.** If you have any objections, suggestions for improvements, bugs, etc, please file them (See [@sec:contributing]). From a99c587d6c09b66bb3ed09090cea0892a9e1c2b7 Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 16:53:27 +0100 Subject: [PATCH 04/13] Split intro into more files Signed-off-by: Matthias Beyer --- doc/src/01000-intro.md | 73 --------------------------- doc/src/01001-intro-problem.md | 21 ++++++++ doc/src/01002-intro-approach.md | 15 ++++++ doc/src/01003-intro-implementation.md | 13 +++++ doc/src/01004-intro-alternatives.md | 26 ++++++++++ 5 files changed, 75 insertions(+), 73 deletions(-) create mode 100644 doc/src/01001-intro-problem.md create mode 100644 doc/src/01002-intro-approach.md create mode 100644 doc/src/01003-intro-implementation.md create mode 100644 doc/src/01004-intro-alternatives.md diff --git a/doc/src/01000-intro.md b/doc/src/01000-intro.md index 3a991b82..205b3b54 100644 --- a/doc/src/01000-intro.md +++ b/doc/src/01000-intro.md @@ -11,76 +11,3 @@ them (See [@sec:contributing]). A way to reach out to the imag project maintainer(s) is described in the [@sec:contributing] section. - -## The Problem {#sec:intro:problem} - -The problem this project tries to solve is to provide a modular commandline -application for personal information management. - -It targets "power users" or "commandline users", uses plain text as a storage -format and tries to be as scriptable as possible. -imag offers the ability to link data from different "PIM aspects" (such as -"diary", "contacts" and "bookmark" for example). - -One major goal of imag is to make the PIM data traverseable and queryable. -For example: a wiki article can be linked to an appointment which is linked to a -todo which is linked to a note which is linked to a contact. - -imag wants to offer an all-in-one scriptable modular commandline personal -information management suite for all PIM aspects one could possibly think of. -Because imag uses plain text (TOML headers for structured data and plain text -which can be rendered using markdown, for example, for continuous text) -the user is always able to access their data without the imag tools at hand. - - -## The Approach {#sec:intro:approach} - -The approach "imag" takes on solving this problem is to store content in a -"store" and persisting content in a unified way. -Meta-information is attached to the content which can be used to store -structured data. -This can be used to implement a variety of "domain modules" using the store. -While content is stored in _one_ place, imag does not duplicate content. -imag does not copy or move icalendar files, emails, vcard files, music or -movies to the store, but tries to remember the actual files are and stores -meta-information about them in the store. - -Detailed explanation on this approach follows in the chapters of this work. - -## Implementation {#sec:intro:implementation} - -The program is written in the Rust programming language. - -The program consists of libraries which can be re-used by other projects -to implement and adapt imag functionality. An external program may use a -library of the imag distribution to store content in the store of imag and -make it visible to imag this way. - -This is a technical detail a user does not necessarily need to know, but as imag -is intended for power-users anyways, we would say it fits here. - -## Alternative Projects {#sec:intro:alternatives} - -imag is not the only project which tries to solve that particular problem. For -example there is -[org mode](https://orgmode.org) -for the [emacs](https://www.gnu.org/software/emacs/) text editor. -There is also [zim](http://zim-wiki.org/), a desktop wiki editor which is -intended to be used for a personal wiki. - -The difference between imag and the mentioned projects is: -* emacs orgmode is (from what I know and see) for _orgabizing_ things. imag is - intended not only for organizing, but also for recording, tracking and - querying. -* zim is a wiki, which could be used for PIM but is not specialized for it. - Recording habits might be possible, but not that simple as with imag - -imag is not there -yet, though. Some parts can be used, though it is far away from being feature-complete. - -In addition: imag is text-editor independent and other tools than imag might be -used to access data stored in the imag store. -For example, one could "grep", "awk" and "sed" entries without much hassle and -even write bash scripts for automatically filling imag entries with data. - - diff --git a/doc/src/01001-intro-problem.md b/doc/src/01001-intro-problem.md new file mode 100644 index 00000000..7be11231 --- /dev/null +++ b/doc/src/01001-intro-problem.md @@ -0,0 +1,21 @@ +## The Problem {#sec:intro:problem} + +The problem this project tries to solve is to provide a modular commandline +application for personal information management. + +It targets "power users" or "commandline users", uses plain text as a storage +format and tries to be as scriptable as possible. +imag offers the ability to link data from different "PIM aspects" (such as +"diary", "contacts" and "bookmark" for example). + +One major goal of imag is to make the PIM data traverseable and queryable. +For example: a wiki article can be linked to an appointment which is linked to a +todo which is linked to a note which is linked to a contact. + +imag wants to offer an all-in-one scriptable modular commandline personal +information management suite for all PIM aspects one could possibly think of. +Because imag uses plain text (TOML headers for structured data and plain text +which can be rendered using markdown, for example, for continuous text) +the user is always able to access their data without the imag tools at hand. + + diff --git a/doc/src/01002-intro-approach.md b/doc/src/01002-intro-approach.md new file mode 100644 index 00000000..4c65d8fe --- /dev/null +++ b/doc/src/01002-intro-approach.md @@ -0,0 +1,15 @@ +## The Approach {#sec:intro:approach} + +The approach "imag" takes on solving this problem is to store content in a +"store" and persisting content in a unified way. +Meta-information is attached to the content which can be used to store +structured data. +This can be used to implement a variety of "domain modules" using the store. +While content is stored in _one_ place, imag does not duplicate content. +imag does not copy or move icalendar files, emails, vcard files, music or +movies to the store, but tries to remember the actual files are and stores +meta-information about them in the store. + +Detailed explanation on this approach follows in the chapters of this work. + + diff --git a/doc/src/01003-intro-implementation.md b/doc/src/01003-intro-implementation.md new file mode 100644 index 00000000..3393eae1 --- /dev/null +++ b/doc/src/01003-intro-implementation.md @@ -0,0 +1,13 @@ +## Implementation {#sec:intro:implementation} + +The program is written in the Rust programming language. + +The program consists of libraries which can be re-used by other projects +to implement and adapt imag functionality. An external program may use a +library of the imag distribution to store content in the store of imag and +make it visible to imag this way. + +This is a technical detail a user does not necessarily need to know, but as imag +is intended for power-users anyways, we would say it fits here. + + diff --git a/doc/src/01004-intro-alternatives.md b/doc/src/01004-intro-alternatives.md new file mode 100644 index 00000000..e50a8fb1 --- /dev/null +++ b/doc/src/01004-intro-alternatives.md @@ -0,0 +1,26 @@ +## Alternative Projects {#sec:intro:alternatives} + +imag is not the only project which tries to solve that particular problem. For +example there is +[org mode](https://orgmode.org) +for the [emacs](https://www.gnu.org/software/emacs/) text editor. +There is also [zim](http://zim-wiki.org/), a desktop wiki editor which is +intended to be used for a personal wiki. + +The difference between imag and the mentioned projects is: +* emacs orgmode is (from what I know and see) for _orgabizing_ things. imag is + intended not only for organizing, but also for recording, tracking and + querying. +* zim is a wiki, which could be used for PIM but is not specialized for it. + Recording habits might be possible, but not that simple as with imag + +imag is not there +yet, though. Some parts can be used, though it is far away from being feature-complete. + +In addition: imag is text-editor independent and other tools than imag might be +used to access data stored in the imag store. +For example, one could "grep", "awk" and "sed" entries without much hassle and +even write bash scripts for automatically filling imag entries with data. + + + From 9e3ce2a297091f0ad16b2486476fce9004b43e92 Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 17:00:09 +0100 Subject: [PATCH 05/13] Rewrite section on crate types Signed-off-by: Matthias Beyer --- doc/src/01010-architecture.md | 53 ++++++++++++++++++----------------- 1 file changed, 27 insertions(+), 26 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. +There are different types of crates in the imag world: -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 + 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 - 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. +These are all libraries. There are also binary crates in the imag project +(though they are technically _also_ library crates): -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. +* "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. -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 From 8c90fb59faa0cd05a8b9f21edc130399ce4e0bf8 Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 17:00:50 +0100 Subject: [PATCH 06/13] State clearly that there could be more Signed-off-by: Matthias Beyer --- doc/src/01010-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/01010-architecture.md b/doc/src/01010-architecture.md index cc00f093..22fbc9cc 100644 --- a/doc/src/01010-architecture.md +++ b/doc/src/01010-architecture.md @@ -53,7 +53,7 @@ With the things from above, a module could have the following architecture: | | | lib | +-----------------+-----------------+ | | | | -| ... | | +| | | | | imag | +-----------------------------------+ | | | | From 55274ad1cd8434357309108a8c827473e5d17ae0 Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 17:01:07 +0100 Subject: [PATCH 07/13] State clearly that this shows only imag stuff Signed-off-by: Matthias Beyer --- doc/src/01010-architecture.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/src/01010-architecture.md b/doc/src/01010-architecture.md index 22fbc9cc..b859da0b 100644 --- a/doc/src/01010-architecture.md +++ b/doc/src/01010-architecture.md @@ -66,6 +66,8 @@ With the things from above, a module could have the following architecture: +-----------------------------------+---------+ ``` +External dependencies are not listed in this graphic. + The foundation of all imag modules is the store, as one can see in the visualization from above. Above the store library there is the libimagrt, which provides the basic runtime From d97dfc2d52c046cf718e5fdda147914fe23bd59f Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 17:02:59 +0100 Subject: [PATCH 08/13] Remove libimagerror, visualize that libimagrt is used in the full stack Signed-off-by: Matthias Beyer --- doc/src/01010-architecture.md | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/doc/src/01010-architecture.md b/doc/src/01010-architecture.md index b859da0b..fed1da41 100644 --- a/doc/src/01010-architecture.md +++ b/doc/src/01010-architecture.md @@ -43,9 +43,9 @@ These are all libraries. There are also binary crates in the imag project With the things from above, a module could have the following architecture: ``` -+---------------------------------------------+ -| imag-foo | +-----------------------------------+---------+ +| imag-foo | | ++-----------------------------------+ | | libimagfoo | | +-----------------+-----------------+ | | | | | @@ -57,11 +57,7 @@ With the things from above, a module could have the following architecture: | | imag | +-----------------------------------+ | | | | -| libimagrt | | -| | error | -+-----------------------------------+ | -| | | -| libimagstore | | +| libimagstore | rt | | | | +-----------------------------------+---------+ ``` @@ -70,17 +66,19 @@ External dependencies are not listed in this graphic. The foundation of all imag modules is the store, as one can see in the visualization from above. -Above the store library there is the libimagrt, which provides the basic runtime -and access to the `Store` object. -Cross-cutting, there is the error library (and possibly -the util library, but we do not care about this one here), which is used through -all levels. The highest level of all imag modules is the commandline interface -on top of the domain library. In between can be any number of entry extension +Above the store level, entry libraries and domain libraries are used to +implement functionality. +The highest level of all imag modules is the commandline interface +on top of the domain library. In between can be any number of entry extension libraries, or none if not needed. +libimagrt is used by the binary to construct the runtime, which itself +constructs and initializes the Store, so this library is used in the full stack +more or less. Theoretically, the commandline interface crate could be replaced to build a terminal user interface, graphical user interface or web interface. + ## Types The imag core, hence the libimagstore, libimagrt and libimagerror, provide a set From 9dce31edb40d85cddfbb70741619dd2dd1c8fd4c Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 17:07:09 +0100 Subject: [PATCH 09/13] Remove notes on libimagerror, as they are not relevant anymore Signed-off-by: Matthias Beyer --- doc/src/01010-architecture.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/doc/src/01010-architecture.md b/doc/src/01010-architecture.md index fed1da41..1cbaffac 100644 --- a/doc/src/01010-architecture.md +++ b/doc/src/01010-architecture.md @@ -81,7 +81,7 @@ terminal user interface, graphical user interface or web interface. ## Types -The imag core, hence the libimagstore, libimagrt and libimagerror, provide a set +The imag core, hence the libimagstore and libimagrt, provide a set of types that a user (as in a library writer) should be aware of. First of all, there is the `Runtime` type which is provided by the libimagrt. It @@ -107,7 +107,3 @@ is the toml-rs crate (external project). Convenience functionality is provided via the `toml-query` crate, which is an external project which was initiated and extracted from the imag project. -Error types are also important. -All errors in imag projects should be created with `error-chain`. -libimagerror provides functionality to enhance the experience with `Result` -types and general tracing of errors. From ffa6e372e1779033878ad02a1752348d7b289f49 Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 17:07:17 +0100 Subject: [PATCH 10/13] Prettify wording Signed-off-by: Matthias Beyer --- doc/src/01010-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/01010-architecture.md b/doc/src/01010-architecture.md index 1cbaffac..5ea8ddff 100644 --- a/doc/src/01010-architecture.md +++ b/doc/src/01010-architecture.md @@ -104,6 +104,6 @@ not on the `FileLockEntry`. The `Entry` provides access to its header, which is a `toml::Value`, where toml is the toml-rs crate (external project). Convenience functionality is provided -via the `toml-query` crate, which is an external project which was initiated and +via the `toml-query` crate, an external project which was initiated and extracted from the imag project. From a5d0cd7a745647e6d050799b065fa5016d87108f Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 17:26:14 +0100 Subject: [PATCH 11/13] Rewrite parts of the Header format section Signed-off-by: Matthias Beyer --- doc/src/02000-store.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/doc/src/02000-store.md b/doc/src/02000-store.md index 07334cea..495ae48a 100644 --- a/doc/src/02000-store.md +++ b/doc/src/02000-store.md @@ -42,21 +42,22 @@ The following section describe their purpose. The header format is where imag stores its data. The header is an area at the top of every file which is seperated from the content part by three dashes (`---`). Between these three dashes there is structured data. imag uses `TOML` -as data format for this structured data, because it fits best and the available -`TOML` parser for the rust programming language is really good. +as data format for this structured data. The header can contain any amount of data, but modules (see @sec:modules) are -restricted in their way of altering the data. +restricted (by convention) in their way of altering the data. -So normally there are several sections in the header. One section (`[imag]`) is -always present. It contains a `version` field, which tells imag which version -this file was created with. +Normally there are several sections in the header. One section (`[imag]`) is +always present, it is automatically created by the store and contains a +`version` field, which tells imag which version this file was created with. +The store automatically verifies that it is compatible (satisfying semver) with +the version of imag an entry was created with, and if it is not, it fails +loading the entry. Other sections are named like the modules which created them. Every module is allowed to store arbitrary data under its own section and a module may never -read other sections than its own. +read or write other sections than its own. -These conventions are not enforced by imag itself, though. ### Content Format {#sec:thestore:fileformat:content} From e8f3d26a4bf1fd42d55b0c952a838f85d4c53f23 Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 17:27:10 +0100 Subject: [PATCH 12/13] Remove notes on markup implementation as not relevant here Signed-off-by: Matthias Beyer --- doc/src/02000-store.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/src/02000-store.md b/doc/src/02000-store.md index 495ae48a..2bac11db 100644 --- a/doc/src/02000-store.md +++ b/doc/src/02000-store.md @@ -63,13 +63,13 @@ read or write other sections than its own. The content is the part of the file where the user is free to enter any textual content. The content may be rendered as Markdown or other markup format for the -users convenience. The store does never expect and specific markup and actually -the markup implementation is not inside the very core of imag. +users convenience. The store does never expect any specific markup. Technically it would be possible that the content part of a file is used to store binary data. We don't want this, though, as it is contrary to the goals of imag. + ### Example {#sec:thestore:fileformat:example} An example for a file in the store follows. From 136b4d3dd9acb1d2295f873d4ae227823a945902 Mon Sep 17 00:00:00 2001 From: Matthias Beyer Date: Sat, 9 Nov 2019 17:30:03 +0100 Subject: [PATCH 13/13] Reword some things on filesystem organization Signed-off-by: Matthias Beyer --- doc/src/02000-store.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/doc/src/02000-store.md b/doc/src/02000-store.md index 2bac11db..cd22d688 100644 --- a/doc/src/02000-store.md +++ b/doc/src/02000-store.md @@ -97,15 +97,13 @@ The "Entries" are stored as files in the "Store", which is a directory the user has access to. The store may exist in the users Home-directory or any other directory the user has read-write-access to. -Each module stores its data in an own subdirectory in the store. This is because -we like to keep things ordered and clean, not because it is technically -necessary. +Each module stores its data in an own subdirectory in the store, by convention. -We name the path to a file in the store "Store id" or "Storepath" and we often +The path to a file in the store is named "Store id" (or short "ID") and we refer to it by using the store location as root. -So if the store exists in `/home/user/store/`, a file with the storepath +So if the store exists in `/home/user/.imag/store/`, a file with the storepath `example.file` is (on the filesystem) located at -`/home/user/store/example.file`. +`/home/user/.imag/store/example.file`. By convention, each `libimagentry` and `libimag` module stores its entries in in `/`.