This file is indexed.

/usr/share/doc/lire/dev-manual/ch23.html is in lire-devel-doc 2:2.1.1-2.1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

 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
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 23. Issues with Report Merging</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Lire Developer's Manual"><link rel="up" href="pt05.html" title="Part V. Implementation Details"><link rel="prev" href="ch22.html" title="Chapter 22. Adding a New Superservice in Lire's Distribution"><link rel="next" href="ch24.html" title="Chapter 24. Overview of Lire scripts"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 23. Issues with Report Merging</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch22.html">Prev</a> </td><th width="60%" align="center">Part V. Implementation Details</th><td width="20%" align="right"> <a accesskey="n" href="ch24.html">Next</a></td></tr></table><hr></div><div class="chapter" title="Chapter 23. Issues with Report Merging"><div class="titlepage"><div><div><h2 class="title"><a name="chap:merging"></a>Chapter 23. Issues with Report Merging</h2></div></div></div><p>In some cases, a merged report doesn't display the right
        information.  We outline some worst case scenarios, and justify our
        implementation.</p><p>Suppose log file 1 (<span class="quote">&#8220;<span class="quote">requests</span>&#8221;</span> with
        <span class="quote">&#8220;<span class="quote">sizes</span>&#8221;</span>) looks like:

              </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>request</th><th>size</th></tr></thead><tbody><tr><td>A   </td><td>12  </td></tr><tr><td>B   </td><td>11  </td></tr><tr><td>C   </td><td>10  </td></tr></tbody></table></div><p>

	while log file 2 looks like:

              </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>request</th><th>size</th></tr></thead><tbody><tr><td>D   </td><td>3   </td></tr><tr><td>E   </td><td>2   </td></tr><tr><td>F   </td><td>1   </td></tr></tbody></table></div><p>

	We report on the top 2 biggest requests, so the report from log 1
	looks like:

              </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>request</th><th>size</th></tr></thead><tbody><tr><td>A   </td><td>12  </td></tr><tr><td>B   </td><td>11  </td></tr></tbody></table></div><p>

	while the report from log 2 would look like:

              </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>request</th><th>size</th></tr></thead><tbody><tr><td>D   </td><td>3   </td></tr><tr><td>E   </td><td>2   </td></tr></tbody></table></div><p>

	Now we change the superservice.cfg file to list the top-4 biggest
	items.  A naive merge would lead to:

              </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>request</th><th>size</th></tr></thead><tbody><tr><td>A   </td><td> 12   </td></tr><tr><td>B   </td><td> 11   </td></tr><tr><td>D   </td><td>  3   </td></tr><tr><td>E   </td><td>  2   </td></tr></tbody></table></div><p>

	Of course, this should've been:

              </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>request</th><th>size</th></tr></thead><tbody><tr><td>A   </td><td> 12   </td></tr><tr><td>B   </td><td> 11   </td></tr><tr><td>C   </td><td> 10   </td></tr><tr><td>D   </td><td> 3    </td></tr></tbody></table></div><p>

            This effect does not occur when keeping the top-limit to the same
            value.  However, when we're not reporting on distinct values in the
            log, but are summing, more horrible things might happen.  Consider
            this: We want to report on the total size by client.  Logs look
            like:

              </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>client</th><th>size</th></tr></thead><tbody><tr><td>a     </td><td> 12 </td></tr><tr><td>b     </td><td> 11 </td></tr><tr><td>c     </td><td> 10 </td></tr></tbody></table></div><p>

	and

              </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>client</th><th>size</th></tr></thead><tbody><tr><td>d     </td><td> 4  </td></tr><tr><td>e     </td><td> 4  </td></tr><tr><td>c     </td><td> 3  </td></tr></tbody></table></div><p>

	Reports from these logs would look like:

              </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>client</th><th>size</th></tr></thead><tbody><tr><td>a     </td><td>12  </td></tr><tr><td>b     </td><td>11  </td></tr></tbody></table></div><p>

              </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>client</th><th>size</th></tr></thead><tbody><tr><td>d     </td><td>4  </td></tr><tr><td>e     </td><td>4  </td></tr></tbody></table></div><p>

	After naively merging, one would get:

              </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>client</th><th>size</th></tr></thead><tbody><tr><td>a    </td><td> 12  </td></tr><tr><td>b    </td><td> 11  </td></tr></tbody></table></div><p>

	In fact, the complete report should look like:

              </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>client</th><th>size</th></tr></thead><tbody><tr><td>c    </td><td> 13  </td></tr><tr><td>a    </td><td> 12  </td></tr></tbody></table></div><p>

        </p><p> Luckily, the <span class="application">Lire</span> merging algorithm is not
	<span class="emphasis"><em>this</em></span> naive: in fact, the XML reports
	store a little more records than actually needed.  This
	heuristic trick leads to sane merged reports in most cases.
	However, since this is merely a heuristic trick, it is no
	waterproof guarantee. 
      </p><p>See the description of the guess_extra_entries routine in the
        Lire::Group manpage for more implementation details.
      </p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch22.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="pt05.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch24.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 22. Adding a New Superservice in <span class="application">Lire</span>'s Distribution </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 24. Overview of <span class="application">Lire</span> scripts</td></tr></table></div></body></html>