-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathREADME.dev.html
93 lines (78 loc) · 2.8 KB
/
README.dev.html
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
<!DOCTYPE HTML>
<html>
<head>
<meta charset="utf-8">
<meta name="description" content="Code structure for srd">
<meta name="author" content="Jeff Abrahamson">
<style type="text/css">
body {
font-family: "lucida grande", Arial, Helvetica, sans-serif;
font-size: 14px;
}
</style>
</head>
<body>
<header>
<h1>About the <b>srd</b> code.</h1>
</header>
<article>
<p>
This is a quick tour of the <b>srd</b> source code.
</p>
<h2>Functional Overview</h2>
<p>
From a functional viewpoint, srd manages a set of text fragments.
Think of them as text on sticky (PostIt(TM)) notes. Each text
fragment has a name, which is also text. Text may be retrieved from a
single note or from multiple notes and is searchable. We'll refer to
the name and the note as key and payload.
</p>
<h2>Implementation Overview</h2>
<p>
The implementation principle is an index (called
the root) and a bunch of files (called leaves). The root is a file
that maps user-readable names (which can be changed by the user) to
permanent names (numbers) to file names for text fragments (which text
fragments may also be changed by the user). The root also remembers a
hash of the password so that we may verify that the user has provided
a reasonable password.
</p>
<h2>File Overview</h2>
<p>
The principle entry point for the program is <b>main.cpp</b>. In other
words, it contains <tt>main()</tt>. It handles option parsing.
Everything else is (at least conceptually) library.
</p>
<p>
The index object is <b>root.cpp</b>. It is tested by <b>root_test.cpp</b>.
</p>
<p>
The root's main data structure is a leaf_proxy_map (implemented in
<b>leaf_proxy_map.cpp</b>, tested by <b>leaf_proxy_test.cpp</b>). The
leaf_proxy_map is also the abstraction by which we return search
results, facilitating searching on existing results. Said differently
the root is a leaf_proxy_map with persistence.
</p>
<p> A leaf proxy (<b>leaf_proxy.cpp</b>) represents a leaf without
loading the data. Once we load the file, the leaf proxy contains a
pointer to the leaf (<b>leaf.cpp</b>, tested in <b>leaf_test.cpp</b>).
<i>(I need to remember the name for this design pattern and mention it
here. I realized recently that I use design patterns quite
extensively, but I somehow managed not to remember most of their names.)</i>
</p>
<p> The file <b>compress.cpp</b> (tested by <b>compress_test.cpp</b>) and
<b>crypt.cpp</b> (tested by <b>crypt_test.cpp</b>) are mixins that
handle compression/decompression and encryption/decryption
respectively.
File operations are abstracted in the mixin class <b>file.cpp</b> (tested by
<b>file_test.cpp</b>). <b>mode.cpp</b> (tested in
<b>mode_test.cpp</b>) isolates a bit of global state: verbose mode and
test mode.
</p>
<p>
Many of the tests require text to manipulate. The file <b>test_text.cpp</b>
provides that text.
</p>
</article>
</body>
</html>