comparison docs/INTERNALS @ 90:9cf0d605465a noffle

[svn] Move INTERNALS to docs/
author bears
date Fri, 19 May 2000 08:59:51 +0100
parents
children
comparison
equal deleted inserted replaced
89:f17eb481c126 90:9cf0d605465a
1 -------------------------------------------------------------------------------
2 NOFFLE Internals
3 -------------------------------------------------------------------------------
4
5 This document is, for the moment, a collection of jottings on aspects
6 of Noffle internals.One day it might make it into something resembling
7 documentation, but I wouldn't put your money on it. Use the Source,
8 Luke!
9
10 1. Where do things get stored?
11
12 Articles: Articles are held keyed by Message-ID in the articles
13 database, articles.gdbm. This is handled by database.[hc]. Articles
14 are marked with a status, indicating if they were only partially
15 downloaded (think overview mode) or if something went wrong on
16 retrieval.
17
18 Groups: The list of groups known is held in the groups database,
19 groupinfo.gdbm, keyed on group name. This holds the group first and
20 last article numbers, the last article number read on the remote
21 server, group creation and last access times, plus the group
22 description, the name of the server from which the group is drawn and
23 a flag indicating if posting to the group is allowed.
24
25 Local groups are indicated as belonging to a special server. They are
26 for the most part treated identically to remote groups (though the
27 whole business of auto-subscribe and auto-unsubscribe obviously
28 doesn't apply, and posting operates locally).
29
30 The fetchlist (fetchlist.[hc]) holds the list of group names Noffle
31 currently subscribes to, and the subscription mode.
32
33 Subscribed groups may have a file with their name in the overview
34 directory. This file - the overview file - contains details of the
35 articles in the group that can currently be read from the server. Each
36 entry in the file is an overview (over.[hc]), while a group overview
37 file is handled by content.[hc]. If no articles are left in a group,
38 the overview file is deleted.
39
40 The Noffle server loads the overview for a group into memory when it
41 needs to manipulate the group and uses its reckoning on the first and
42 last article number from there on. This may not correspond with the
43 first and last number given in the groups database entry. Typically,
44 the database first and last entries are updated from the overview on
45 completion of actions affecting the group.
46
47 Outbound articles are placed in a directory under the Noffle spool
48 'outgoing' directory. Each is in its own file, named by the article
49 Message-ID, in a directory with the name of the server. outgoing.[hc]
50 handle tracking what outbound messages are queued and queueing new ones.
51 When Noffle connects to the appropriate server, the message is posted
52 on and the file removed.
53
54 2. Posting
55
56 Posting to remote groups is straightforward; the article is placed in
57 the outgoing queue, and will be read back from the server as part of
58 collecting new messages for the group. The article is placed once only
59 in the queue, regardless of the number of external groups, as it only
60 needs to appear once on the remote server. Articles posted only to
61 newsgroups unknown to Noffle are rejected.
62
63 If the group is marked as 'can't post' ('n' in LIST ACTIVE) the post
64 is rejected immediately. Note you can't have moderated local groups at
65 the moment; you can have read-only ones, though.
66
67 Control message are similarly passed on, unless the control is
68 'cancel' and the cancel can be done entirely locally because the
69 article is still in the outgoing queue.
70
71 Posts to local groups appear in the article database
72 immediately. Control messages (control.[hc]) for local groups are
73 honoured, though currently only 'cancel' does anything.
74
75 Things get more complex when an article is cross-posted to a local and
76 remote group. Essentially, both the above happen; if the remote server
77 does not change the Message-ID, the local copy will be the definitive
78 for both groups. Obviously if the remote server does change the
79 Message-ID, Noffle will tread the article coming back from the server
80 as a new one.
81
82 post.[hc] holds the code for posting local articles.
83
84 The posting code in post 1.0 Noffle should (i.e. I'll do it if time
85 permits) be rearranged to provide one function to post (or reject) an
86 article regardless of original source. This would hopefully make it
87 clearer what happens during a post, and make it easy to add a
88 command-line article post function, which could remove the necessity
89 for Python or Perl intervention gateing mailing lists into local newsgroups.
90
91 3. Pseudo articles
92
93 Noffle generates various pseudo articles itself (see pseudo.[hc]), to
94 inform the user of changes of state or to give instruction. All but
95 one are, in fact, done by generating and posting a regular article,
96 but one is special; the general information article.
97
98 The gen info article is the one shown when one tries to read from a
99 currently unsubscribed (Noffle is not subscribed to it, that it)
100 newsgroup. It is apparently present in every single group known to
101 Noffle, but is faked; it never appears in the article database. LIST
102 ACTIVE fakes the first and last article numbers for a group if it
103 knows the group is not subscribed to (and not local), and entry to a
104 group with the GROUP command will cause an overview to be added to the
105 group overview in memory only. If the article is not read, the
106 overview is lost unsaved when moving to the next group.
107
108 Reading the article triggers stuff happening. If auto-subscribe is on,
109 a pseudo article confirming subcription is posted and the group
110 overview saved. Gen info articles are not normally saved in overviews,
111 but to prevent them vanishing very suddenly their overview is saved
112 with other articles in the group if they form part of the sequence of
113 the group. In this case it will persist until the subscription confirm
114 article expires. This will not stop another gen info being generated
115 if (say) the group gets auto-unsubscribed.