1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
# The Store {#sec:thestore}
The store is where all the good things happen.
The store is basically just a directory on the filesystem imag manages and keeps
its state in.
One could say that the store is simply a database, and it really is. We opted
to go for plain text, though, as we believe that plain text is the only sane way
to do such a thing, especially because the amount of data which is to be
expected in this domain is in the lower Megabytes range and even if it is
_really_ much won't exceed the Gigabytes ever.
Having a storage format which is plain-text based is the superior approach, as
text editors will always be there.
A user should always be able to read her data without great effort and putting
everything in a _real_ database like sqlite or even postgresql would need a user
to install additional software just to read his own data. We don't want that.
Text is readable until the worlds end and we think it is therefore better to
store the data in plain text.
The following sections describe the store and the file format we use to store
data. One may skip the following sections, they are included for users who want
to dig into the store with their editors.
## File Format {#sec:thestore:fileformat}
The contents of the store are encoded in UTF-8.
A normal text editor (like `vim` or the other one) will always be sufficient to
dig into the store and modify files.
For simple viewing even a pager (like `less`) is sufficient.
Each entry in the store consists of two parts:
1. Header
1. Content
The following section describe their purpose.
### Header Format {#sec:thestore:fileformat:header}
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.
The header can contain any amount of data, but modules (see @sec:modules) are
restricted (by convention) in their way of altering the data.
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 or write other sections than its own.
### Content Format {#sec:thestore:fileformat:content}
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.
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.
```text
---
[imag]
version = "0.10.0"
[note]
name = "foo"
[link]
internal = ["some/other/imag/entry"]
---
This is an example text, written by the user.
```
## File organization {#sec:thestore:fileorganization}
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.
We name the path to a file in the store "Store id" or "Storepath" and we often
refer to it by using the store location as root.
So if the store exists in `/home/user/store/`, a file with the storepath
`example.file` is (on the filesystem) located at
`/home/user/store/example.file`.
By convention, each `libimagentry<name>` and `libimag<name>` module stores its
entries in in `<name>/`.
So, the pattern for the storepath is
```
<module name>/<optional sub-folders>/<file name>
```
Any number of subdirectories may be used, so creating folder hierarchies is
possible and valid.
A file "example" for a module "module" could be stored in sub-folders like this:
```
module/some/sub/folder/example
```
The above is not enforced or a strict rule, but rather a "rule of thumb".
## Backends {#sec:thestore:backends}
The store itself also has a backend. This backend is the "filesystem
abstraction" code.
Note: This is a very core thing. Casual users might want to skip this section.
### Problem {#sec:thestore:backends:problem}
First, we had a compiletime backend for the store.
This means that the actual filesystem operations were compiled into the store
either as real filesystem operations (in a normal debug or release build) but as
a in-memory variant in the 'test' case.
So tests did not hit the filesystem when running.
This gave us us the possibility to run tests concurrently with multiple stores
that did not interfere with each other.
This approach worked perfectly well until we started to test not the
store itself but crates that depend on the store implementation.
When running tests in a crate that depends on the store, the store
itself was compiled with the filesystem-hitting-backend.
This was problematic, as tests could not be implemented without hitting
the filesystem and mess up other currently-running tests.
Hence we implemented store backends.
### Implementation {#sec:thestore:backends:implementation}
The filesystem is abstracted via a trait `FileAbstraction` which
contains the essential functions for working with the filesystem.
Two implementations are provided in the code:
* FSFileAbstraction
* InMemoryFileAbstraction
whereas the first actually works with the filesystem and the latter
works with an in-memory HashMap that is used as filesystem.
Further, the trait `FileAbstractionInstance` was introduced for
functions which are executed on actual instances of content from the
filesystem, which was previousely tied into the general abstraction
mechanism.
So, the `FileAbstraction` trait is for working with the filesystem, the
`FileAbstractionInstance` trait is for working with instances of content
from the filesystem (speak: actual Files).
In case of the `FSFileAbstractionInstance`, which is the implementation
of the `FileAbstractionInstance` for the actual filesystem-hitting code,
the underlying resource is managed like with the old code before.
The `InMemoryFileAbstractionInstance` implementation is corrosponding to
the `InMemoryFileAbstraction` implementation - for the in-memory
"filesystem".
|
