2 |
<html> |
<html> |
3 |
<head> |
<head> |
4 |
<title>PEG 1001</title> |
<title>PEG 1001</title> |
5 |
|
|
6 |
<meta http-equiv="content-type" |
<meta http-equiv="content-type" |
7 |
content="text/html; charset=ISO-8859-1"> |
content="text/html; charset=ISO-8859-1"> |
8 |
</head> |
</head> |
9 |
<body> |
<body> |
10 |
|
|
11 |
<h1>PEG 1001: Generic indexing API</h1> |
<h1>PEG 1001: Generic indexing API</h1> |
12 |
|
<p><i> |
13 |
|
Author: Tuomas Lukka |
14 |
|
</i></p> |
15 |
<br> |
<br> |
16 |
|
|
17 |
<p>Replace SearchableText with a more general indexing API where the user |
<p>Replace SearchableText with a more general indexing API where the user |
18 |
can specify how to match strings. This change would also make the <tt>core</tt> |
can specify how to match strings. This change would also make the <tt>core</tt> |
19 |
uml diagram accurate: no classes in the package <tt>gzz</tt> would exist that |
uml diagram accurate: no classes in the package <tt>gzz</tt> would exist that |
20 |
aren't documented there. The proposed changes include<br> |
aren't documented there. The proposed changes include<br> |
21 |
</p> |
</p> |
22 |
|
|
23 |
<ul> |
<ul> |
24 |
<li>Split StringSearcher into an Index and Indexer API, one for reading, |
<li>Split StringSearcher into an Index and Indexer API, one for reading, |
25 |
the other for writing.</li> |
the other for writing.</li> |
26 |
<li>Create classes to represent different index types</li> |
<li>Create classes to represent different index types</li> |
27 |
<li>Create a central class <tt>SpaceIndexManager</tt> which can create |
<li>Create a central class <tt>SpaceIndexManager</tt> which can create |
28 |
an index of the given type for a given space.</li> |
an index of the given type for a given space.</li> |
29 |
<li>Create new package <tt>gzz.index</tt> to hold indexing-related classes</li> |
<li>Create new package <tt>gzz.index</tt> to hold indexing-related classes</li> |
30 |
|
|
31 |
</ul> |
</ul> |
32 |
|
|
33 |
|
<p> |
34 |
|
<small>(Benja:) That sounds like premature abstraction to me: I wouldn't know how to |
35 |
|
implement this. But if you do, fine.</small> |
36 |
|
</p> |
37 |
|
|
38 |
The classes in the core APIs (the ones visible to the frontend) would then |
The classes in the core APIs (the ones visible to the frontend) would then |
39 |
be<br> |
be<br> |
40 |
<ul> |
<ul> |
45 |
</li> |
</li> |
46 |
</ul> |
</ul> |
47 |
Issues<br> |
Issues<br> |
48 |
|
|
49 |
<ul> |
<ul> |
50 |
<li>How to specify search types? Ignore-case, regex, match only at beginning, |
<li>How to specify search types? Ignore-case, regex, match only at beginning, |
51 |
match only whole words etc.</li> |
match only whole words etc. <br> |
52 |
|
<small>(Benja:) Through the index instance, IMHO, i.e. you create different index |
53 |
|
instances for the different policies. Or maybe your searcher/indexer |
54 |
|
separation could come in here: you could have different searcher |
55 |
|
policies using the same data store built by a single indexer, potentially. |
56 |
|
</small> |
57 |
|
</li> |
58 |
<li>How to make index management as general as possible? Or should we |
<li>How to make index management as general as possible? Or should we |
59 |
keep to cell content indexing for now?</li> |
keep to cell content indexing for now?<br> |
60 |
<li>Can we implement Xanalogical text search at the same time, with the |
<small>(Benja:) By using <tt>Object</tt>s as the keys, not <tt>Cell</tt>s, |
61 |
|
and by not making the <tt>String*</tt> classes dependent on |
62 |
|
the zzstructure APIs. I don't think that the spaces should index |
63 |
|
things other than cell content through this interface, though. |
64 |
|
</small> |
65 |
|
</li> |
66 |
|
<li>Can we implement Xanalogical text search at the same time, with the |
67 |
same APIs?<br> |
same APIs?<br> |
68 |
|
<small>(Benja:) I don't think so.</small> |
69 |
</li> |
</li> |
70 |
|
|
71 |
</ul> |
</ul> |
72 |
<br> |
<br> |
73 |
<br> |
<br> |