derek (02/05/83)
There seems to be a problem with expiring newsgroups. I would like to suggest the following method of storing news on a system to cure this. o There should be one directory on a system which contains all news items. Each news item is stored in its own file and the name of the file is the article ID. o There should be one file which contains a list of newsgroups to which the site may post news. This file exists under the present system and is called 'ngfile'. o There should be one history file for each newsgroup. This file contains the article ID, a date and sequence number for that date, and, an optional expiry date. o Each user has a file in his/her home directory indicating readnews options and which articles have been read by recording the date-sequence numbers. o The sys file, indicating to which sites news items are passed, exists in its present format. When articles expire, all reference to them is removed from the history files and the news file is deleted. When all items of a particular group have disappeared, then the group no longer exists. The current interfaces for posting news and reading news function as they do presently (and with any new features as they arise). Any comments? Derek Andrew U of Saskatchewan
sjb (02/06/83)
A few replies to your 'news system': 1) One directory containing ALL articles -- Congratulations! You have just reinvented A news! The basic flaw (and it's pretty nasty) is that this scheme causes extremely looooong directory lookups when news is searching for articles. That's why B news puts every newsgroup in its own directory. 2) One ngfile -- Again, you've just recreated A news. B news' approach to an active file AND an ngfile is neat: The active file shows what groups are available to read and in what order they will be read. The ngfile shows which groups can be posted to LOCALLY, thus you can prevent people from accidentally posting to fa groups by !'ing out fa.all in the ngfile. 3) One history file per group -- This has its advantages and flaws. I would like to see some discussion about making a /usr/lib/news/history directory and then giving each group its own history file by group name in that directory. This would speed some things up a bit, since expire would not have to plow through a huge history file every night. However, I would think the extra time spent finding, opening, and closing each file would also slow it down. 4) A sequencer type thing -- Now you're making notesfiles. Why should news record the last time a person read each group rather than the list of articles read in that group. If it takes the former approach, then people would not be able to skip over articles for later perusal (e.g. I see a long article on a topic I like while at work; not wanting to 'waste' company time/money reading and responding to it, I save it until that night or the weekend, when I can devote my full energies to it. With a sequencer type thing, I'd have to go looking through all of news again. The way it is now, B news just shows it to me again automatically.) In general, it appears to me that you're regressing to past, dark days. Most of the stuff you propose (numbers 1, 2, and 4) would slow news down considerably and make it much more clumsy to use. Number 3 has very good merits, and I think we should discuss it some more and see what can be done with it.
trt (02/11/83)
References: alice.1468 Some comments on the recent Derek Andrew/Adam Buchsbaum discussion. 1. Where A news stores its articles is relevant only to its efficiency. Yes, the old way was amazingly slow. Newer versions put articles in subdirectories. They might yet get put into a dbm(III) file. The articles are accessed only by their article-id; it matters little how they are stored so long as they can be accessed efficiently. (There is also an auxiliary 'news-index' file which permits accessing articles by date, newsgroup, or title.) The point of Derek's suggestion, I think, is to allow accessing articles by article-id. For example, if I see that an article references "sri-ai.1234", I can just type news sri-ai.1234 to look at the article. This mechanism is useful only if people use 'followup' or otherwise reference article-ids. I suppose that since B news readers do not use article-ids much they have little incentive to supply them. 2. History files, I believe, are used to reject article duplicates. They are not not needed with A news since it is fast and easy to check if an article is already online. (There is a problem, however, that if an article is cancelled and then arrives again from some slower transmission path, the article would be re-inserted and re-transmitted. To block them, cancelled articles leave "stubs" for two weeks.) Tom Truscott