1 6/3/84 Enhancements to the Forum subsystem
2
3 This info segment briefly describes the enhancements made to the
4 Forum subsystem.
5
6
7 7/13/83 List of enhancements in version 2.0:
8 1 new meeting structure
9 2 access control and other file system operations
10 3 managing a meeting directory
11 4 perusing changed meetings
12 5 the transaction "seen" map
13 6 subroutine interface changes
14
15
16 New meeting structure:
17 Version 2 Forum meetings, those meetings created with the
18 v2_forum_create command instead of the forum_create command, are
19 implemented as directories with the suffix "forum" instead of as two
20 segments with the suffixes "control" and "proceedings". This removes
21 almost all of the limitations on the size and number of attendees of a
22 meeting. A new command, convert_forum, has been provided to convert a
23 version 1 meeting into a version 2 meeting. Version 2 forum will
24 continue to support unconverted meetings, but those meetings will
25 continue to be subject to size constraints, and will not be able to
26 take advantage of some new features.
27
28
29 Access control and other file system operations:
30 Version 2 meetings are Multics "extended objects". This means that if
31 your site has installed the extended object software, meetings may be
32 manipulated with the standard file system commands such as copy,
33 delete, list_acl, and set_acl.
34
35 Access to meetings is controlled by extended ACL terms. Three modes
36 are defined: read r, write w, and chairman c. To make a meeting
37 publicly readable and to make user Smith a chairman of the meeting, the
38 command
39
40 set_acl <meeting_name>.forum r *.* rwc Smith.*
41
42 may be used. Similarly, the list_acl command may be used to list the
43 eligibility to a meeting, and the delete_acl command may be used to
44 remove an access term.
45
46
47 The switch_on/switch_off command may be used to set the safety switch
48 on a meeting, or to change the value of any other switch accepted by
49 forum, such as "notify". The copy and move commands may be used to
50 move a meeting to another location in the storage system heirarchy,
51 and the delete command may be used to delete a meeting.
52
53
54 If your site has not installed the extended object software, you may
55 continue to use the forum access commands forum_add_participant
56 forum_make_public etc. and the forum_delete command on version 2
57 meetings. The -chairman control argument has been added to allow the
58 access commands to give 'c' access to a meeting. However, privileged
59 access is required to move or copy a meeting.
60
61
62 Managing a meeting directory:
63 Two new commands have been provided to assist users in managing the list
64 of meetings that they attend. The forum_add_meeting fam command, also
65 available as the add_meeting am request, is used to add a meeting to
66 the list of meetings attended. The forum_remove_meeting frm command,
67 also available at the remove_meeting rm request, will remove a
68 meeting from that list.
69
70 Version 2 forum also provides a facility for announcing the existence
71 of a meeting. The forum_create command will offer to do this, or
72 the new announce_meeting anm request may be used. The announcement
73 consists of a formatted transaction entered in a specified meeting, the
74 default is forum_dir>Meeting_Directory, which can be understood by
75 the add_meeting request.
76
77
78 If the last transaction in the Meetings_Directory meeting is an
79 announcement of a meeting that you would like to attend, the request
80
81 add_meeting last
82
83 will make you a participant of the announced meeting.
84
85
86 Perusing changed meetings:
87 Two new requests have been added to simplify the daily perusal of all
88 changed meetings. The check_meetings ckm request scans the forum
89 search list and remembers all of the meetings that have changed. The
90 next_meeting nm request may then be used to attend each meeting in
91 turn.
92
93
94 The transaction "seen" map:
95 In version 2 meetings, forum remembers whether a user has seen each
96 transaction, not just the most recent transaction that has been read.
97 Each transaction may be marked as either seen or unseen. A transaction
98 is marked as seen by the print and write requests, and the seen switch
99 may be explicitly manipulated with the switch_on and switch_off
100 requests. Transactions are also marked as seen by their author when
101 they are entered. Ten new transaction specifiers and requests have been
102 added to utilize the seen switch. They are: seen, first_seen,
103 last_seen, next_seen, previous_seen, unseen, first_unseen, last_unseen,
104 next_unseen, and previous_unseen.
105
106
107 Subroutine interface changes:
108 New entries have been added to the forum_ subroutine in order to take
109 advantage of the new features of version 2 meetings. Most important
110 to forum application writers is the changes resulting from the transaction
111 seen map. The forum_$set_last_seen_idx entrypoint may not be used with
112 version 2 meetings. Instead, the forum_$set_seen_switch entry should be
113 called to set or reset the seen switch for a particular transaction. The
114 forum_$get_transaction_map and forum_$get_transaction_map_idx entries may
115 be used to retrieve this information.
116
117 If these new entrypoints are asked to operate on version 1 meetings, the
118 error code forum_error_table_$old_format will be returned.
119
120
121 Some incompatible changes in calling sequences were made, and the old
122 entrypoints were renamed so that both meeting types may be supported
123 by the forum_ gate. The set_v1_forum_acl, list_v1_forum_acl, and
124 v1_expunge entries must be used in place of the set_forum_acl,
125 list_forum_acl, and expunge entries on version 1 meetings. If the version
126 of the meeting is unknown, the following code fragment is recommended:
127
128 call forum_$list_forum_acl ....;
129 if code ^= 0 then
130 if code = forum_error_table_$old_format then
131 call forum_$list_v1_forum_acl ...;
132
133
134 6/26/83 List of enhancements in version 1.10 MR10.2:
135 1 changes to the qedx and ted requests
136 2 transaction deletion
137 3 transaction selection
138 4 formatted output
139 5 the exec_com request
140
141
142 Changes to the qedx and ted requests:
143 The qedx and ted requests, as well as the editor entered by terminating
144 transaction input with \f, have been incompatibly changed to require the
145 use of the write request to save editing changes. The quit request will
146 no longer automatically save all editing changes.
147
148
149 If the quit request is issued and the transaction has been modified since
150 it was last written, the editor will now query for permission to exit. If
151 permission is given, any changes made since the last write will be
152 lost. The new quit-force qf request may be used to abort unwanted
153 editing of the transaction without being queried.
154
155 The read r and write w requests still accept pathnames and may be
156 used to insert a segment into the transaction or make a copy in a segment
157 for later use, respectively. However, when used with a pathname, these
158 requests will no longer change the default pathname for buffer 0 the
159 transaction. Using either read or write without a pathname will always
160 refer to forum's copy of the transaction.
161
162
163 The request line
164 1,$dr
165 will only restore the original transaction text to the buffer if the write
166 request has not yet been used. If given after a write request, this
167 request line will restore the transaction text as saved by the last write
168 request in the buffer.
169
170
171 Transaction deletion:
172 Any participant may now delete a transaction that he has entered. A
173 participant may also retrieve any deleted transactions that he authored
174 provided that they were deleted by him, and not by the chairman.
175
176
177 Transaction selection:
178 Many improvements to transaction selection have been made. Transactions
179 may now be selected by date-time. The -after, -after_time, -before,
180 -before_time, -between, -between_time, and -date control arguments allow
181 the selection of transactions entered after, before, or during a specific
182 period of time.
183
184 The -include_deleted, -only_deleted, and -only_non_deleted control arguments
185 have been added to allow selection of deleted transactions. Only those
186 deleted transactions that were entered by a participant may be selected
187 by participants other than the chairman.
188
189
190 A new transaction specifier, highest last_seen, has been added. The
191 definition of the restref transaction specifier has been changed to
192 not include the current transaction.
193
194 The -by_chain control argument has been added to sort selected
195 transactions into transaction chains.
196
197 Type "help trans_specs" from inside forum for a complete description of
198 transaction specifiers.
199
200
201 Formatted output:
202 The write request has been upgraded to produce formatted output. The
203 -format and -page_length control arguments were added. This produces
204 page-oriented output consisting of a header line giving the date,
205 meeting name, and page number; a footer line giving the subject of the
206 first transaction on the page; and "fence" lines separating the header
207 and footer from the transaction text. A single transaction will not be
208 split across a page boundary unless it is longer than a page.
209
210
211 The exec_com request:
212 Forum is now able to execute a segment containing forum requests
213 through the use of the exec_com ec request. A forum exec_com is just
214 like a Multics exec_com file except that it contains forum request
215 lines instead of Multics command lines. Also, these segments must have
216 the ".fmec" suffix on their names.
217
218 Forum will also look for a "start_up.fmec" segment in the user's
219 homedir, project directory, and >site. The -no_start_up -nsu control
220 argument was added to suppress this feature.