home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / news / cnews.tar / doc / nov < prev    next >
Text File  |  1993-06-25  |  5KB  |  147 lines
  1. .TL
  2. The Design of a Common Newsgroup Overview Database for Newsreaders
  3. .AU
  4. Geoff Collyer
  5. .AI
  6. Software Tool & Die
  7. .AB
  8. Every new newsreader seems to come with a requirement
  9. for a private database of tens of megabytes of article headers.
  10. Some of these database maintenance programs are inordinately costly
  11. to run.
  12. We present the design and rationale of a newsreader database
  13. that is sharable by multiple newsreaders and relatively cheap to maintain.
  14. .AE
  15. .SH
  16. Background
  17. .PP
  18. Two of the most popular newsreaders,
  19. .I nn
  20. and
  21. .I trn ,
  22. have been around for several years and
  23. each has its own private binary database of article headers
  24. (and other information),
  25. which are intended to avoid the considerable expense of opening all
  26. the articles in a newsgroup in order to present a menu of choices
  27. to the user.
  28. .I nn 's
  29. database maintainer,
  30. .I nnmaster ,
  31. has been getting faster over the years
  32. and appears not to be much of a load on the system.
  33. .I trn 's
  34. database maintainer,
  35. .I mthreads ,
  36. manages to consume vast quantities of both CPU and disk bandwidth.
  37. Neither database format is documented,
  38. even by comments in the source code of its maintenance program
  39. (and
  40. .I trn 's
  41. is truly bizarre).
  42. Since the maintenance programs tended to be slow and run asynchronously
  43. with the rest of the news transport,
  44. new articles tended to be unavailable for some time after arrival to users
  45. of these news readers.
  46. The binary nature of the database files means that access over networks
  47. involves byte-swapping
  48. and dealing with the differing sizes of various data types across
  49. machine architectures.
  50. .PP
  51. To add to this discouraging scenario,
  52. new newsreaders,
  53. such as
  54. .I tin
  55. and
  56. .I tass ,
  57. have been appearing more recently,
  58. requiring their own private databases.
  59. Clearly something had to be done before private databases dwarfed the
  60. actual news spool and their maintenance programs consumed most of the
  61. resources of their host systems.
  62. .SH
  63. The New Scheme
  64. .PP
  65. .I relaynews
  66. (the C News analogue of B News's
  67. .I rnews )
  68. has the article headers in hand during processing of that article,
  69. so having it simply write a stream of all the article headers
  70. onto the end of a file
  71. is sufficient to make that information available cheaply
  72. and without making policy decisions about which headers to omit.
  73. Writing a little program that massages that stream
  74. into a more compact format,
  75. and updates the common database,
  76. completes the updating of the database.
  77. A nightly expire that deletes obsolete database entries completes
  78. database maintenance.
  79. .PP
  80. The database itself consists of a text file
  81. in each news spool directory with a fixed name
  82. (\c
  83. .B .overview ).
  84. Each line of such a file consists of commonly-needed header fields,
  85. separated by tabs.
  86. There is provision for extensions beyond the commonly-needed set,
  87. and these require only cook-book changes to the program that massages
  88. the header stream.
  89. Experimentation suggests that on-the-fly threading by
  90. .B References:
  91. headers is cheap enough
  92. that there is no benefit to storing threading information in the
  93. database,
  94. thereby avoiding the costly updating of said threading information.
  95. .PP
  96. A library to read and thread the overview files is provided.
  97. .br
  98. .ne 1i
  99. .SH
  100. Comparison of the Old and New Schemes
  101. .PP
  102. .I nn
  103. and
  104. .I trn
  105. have successfully had their database-reading routines
  106. replaced by calls on the common database reader library;
  107. most of the work here was emulating the peculiar assumptions each
  108. reader made about the work done by its database maintainer.
  109. Somewhat less work was understanding the interface presented by
  110. the database-reading routines to the rest of the reader.
  111. The new versions of these readers appear to consume somewhat more memory,
  112. but this may be curable by someone more knowledgable of the readers
  113. internals, and seems a small price to pay for the ability to use
  114. a common database.
  115. .I vnews
  116. has had thread-following added;
  117. the work here was primarily understanding the workings of
  118. .I vnews .
  119. .PP
  120. It seems that the new database and its access library
  121. are sufficient to meet the needs of modern newsreaders.
  122. The new database has no byte-ordering problems and should be
  123. easier to access over networks than the old databases.
  124. The new database is updated after each
  125. .I relaynews
  126. invocation in
  127. .I newsrun ,
  128. so articles are available to users quickly,
  129. and the incremental database updates seem to be cheap.
  130. The new database format is extensible,
  131. so future demands should not strain the database format.
  132. .PP
  133. The old private databases were generally not accessible via NNTP
  134. (unless one added the
  135. .I trn
  136. XTHREAD modifications to one's NNTP server),
  137. so the databases were generally exported via NFS.
  138. This seems like a sensible way to proceed
  139. and simply exporting
  140. .B /usr/spool/news
  141. via NFS
  142. (read-only if you like)
  143. will export the new database too.
  144. However,
  145. it is possible that the NNTP v2 or NNRP committees may
  146. make the new database accessible via NNTP or NNRP.
  147.