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
|
# The Store {#sec:thestore}
## File Format {#sec:thestore:fileformat}
The content in the store MUST BE encoded in either Unicode UTF-8 or ASCII.
Each "Entry" (File) MUST HAVE a "Header" component as well as a "Content"
component.
Each "Entry" in the store MUST start with three single dashes ("-") followed
by a newline character, named "initial marker" in the following chapter.
The Header follows the initial marker (@sec:thestore:fileformat:header).
The Header MUST BE followed by a line which contains three single dashes ("-")
and a newline character, called "header-close marker" in the following
chapter.
The content follows the header-close marker (@sec:thestore:fileformat:content).
### Header Format {#sec:thestore:fileformat:header}
The header format MUST BE "TOML".
The contents of the header contain
1. A section called "imag", where the automatically by the program generated
data goes to.
The contents of these sections are edited via commandline calls or by the
program implicitely and SHOULD NOT be edited by the user.
Modules of the program are free to store arbitrary data here.
If a module stores data in the header of a file it MUST do that in a
dedicated section, as TOML supports it.
The name of the section MUST BE the name of the module in lowercase
letters.
The section MAY BE empty.
1. Other OPTIONAL sections which are named and edited by the user. The program
MUST NOT touch the contents of these sections, except explicitely asked by
the user to do so.
### 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 program SHOULD NOT expect any particular markup format, except explicitely
configured in the header of the file.
### Example {#sec:thestore:fileformat:example}
An example for a file in the store follows.
```
---
[imag]
nothing = here
[imag.examplemodule]
and_nothing = here_as_well
---
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.
The Path of each File is shown as absolute path in this paper, while the root
is always the store directory.
This Path is named "Storepath".
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`.
A Storepath contains predefined parts:
* The module name of the Module the Entry belongs to.
This part is a directory.
* The version (semantic versioning applies) of the module storing the Entry
This part is a postfix to the filename
The pattern for the storepath is
```
/<module name>/<optional sub-folders>/<file name>~<sem version>
```
So if a Module named "ExampleModule" with version "0.1" stores a file in the
Store, the Storepath for a file with the name "example" is
"/ExampleModule/example~0.1".
Any number of subdirectories MAY BE used, so creating folder hierarchies is
possible and valid.
A file "example" for a module "module" in version "0.1" would be stored in
sub-folders like this:
```
/module/some/sub/folder/example~0.1
```
## Store path links {#sec:thestore:links}
Linking entries MUST BE version independent.
This means if an entry "a" from a module "A" gets written to the store, it may
link to an entry "b" from a module "B", which is in version "0.1" at the moment.
If the module "B" gets updated, it might update its entries in the store as
well.
The link from the "a" MUST NOT get invalid in this case.
This is accomplished by linking without the version number: So a link for the
entry
```
/module/some/sub/folder/example~0.1
```
is
```
imag://module/some/sub/folder/example
```
As shown in the example, a link to imag-internal entries, the link is prefixed
with a "imag://" identifier.
A link to external content MUST NEVER be prefixed this way.
The path of the internal link MUST NEVER be relative, but always absolute from
the root directory of the store.
|
