Mercurial > hg > discussions
annotate whitepaper.txt @ 3:f09ba04b2e29 default tip
adding notes about -> collaborative documents
author | Jeff Hammel <k0scist@gmail.com> |
---|---|
date | Fri, 26 Mar 2010 14:03:44 -0700 |
parents | 910fa7e781b9 |
children |
rev | line source |
---|---|
2 | 1 Discussions |
2 =========== | |
0 | 3 |
4 All Discussions objects are basically the same. You get a set of | |
5 options which are inherited from the parent or provided. | |
6 | |
2 | 7 Discussions (version 1) is a strict hierarchy with views on this object. |
8 Email messages (as per the python ``email`` module) are used as the | |
9 basis of all message object: that is, each object should be | |
10 expressable as a set of headers and body. Since email messages are | |
11 hierarchal, the organization makes sense | |
12 | |
13 Discussion version 2 is planned to be a directed graph. | |
14 | |
15 Core concepts: | |
16 * events | |
17 * people | |
18 * moderation | |
19 * policy | |
20 | |
21 | |
22 Events | |
23 ------ | |
24 | |
25 The add_message event: this is the portal event for all messages going | |
26 through discussions. This may be via | |
27 | |
28 * email | |
29 * web | |
30 * command line | |
31 | |
32 This could provide a front for twitter, RSS, or other discussions instances. | |
33 | |
34 | |
35 Roles and Permissions | |
36 --------------------- | |
1 | 37 |
38 A member can be in one of three states with respect to a resource: | |
39 | |
40 * administrator: has all rights over a resource except as set by | |
41 above resources; Administrators of the root ('/') resource are | |
42 site administrators and have all rights. | |
43 | |
44 * members: has permissions of a resource as dictated by the | |
45 administrator (view, post, etc). [different types of members? | |
46 groups? probably not] | |
47 | |
48 * non-members: if an agent isn't a member of a resource, they | |
49 generally have lowest level priveleges. | |
50 | |
2 | 51 Options and Configuration |
52 ------------------------- | |
0 | 53 |
2 | 54 Configuration options can be in one of three states: unset, set, and locked (and |
1 | 55 set + locked). In |
0 | 56 the case where the option is locked, all children inherit the setting |
57 as well: | |
58 | |
59 archive.lock = false | |
60 | |
61 Locking an option prohibits any but a higher-level admin from | |
62 unlocking it. The higher-level admin is free to change the setting: | |
63 | |
64 archive.lock = false | |
65 archive = true | |
66 | |
67 This locks the archive of subchildren into the false state, but sets | |
68 the archive for this discussion in the current discussion. | |
69 | |
70 This prevents archiving on any sublist. Messages to a list inherit | |
71 the list settings. | |
72 | |
73 If an option is unset, it will use the settings of its parent, the | |
74 site defaults, or the application default, based on its type | |
75 (Forum or Discussion). | |
76 | |
77 | |
2 | 78 Members |
79 ------- | |
0 | 80 |
2 | 81 Preferences: |
0 | 82 |
1 | 83 Member preferences can also be set from the site level. |
84 | |
2 | 85 |
86 Digest | |
87 ------ | |
1 | 88 |
89 Different templates can be used to display different digest methods. | |
90 For instance, you could display a brief form of the message with just | |
91 the links: | |
92 | |
93 {{{ | |
94 Example of .ini configuration: | |
95 | |
96 [digest:daily] | |
97 template = /path/to/templates/daily-digest.txt | |
98 | |
99 }}} | |
100 | |
101 This can be used to facilitate a moderated digest. Roundup emails can | |
2 | 102 be sent about a discussion written and editted by the moderator. |
103 | |
104 | |
105 Hierarchy Example | |
106 ----------------- | |
107 | |
108 Both Forum and Conversation objects are MessageContainers. | |
109 | |
110 /foo | |
111 bar/--message 1 | |
112 | | | |
113 | +-reply to message 1 | |
114 | | | | |
115 | | \-"..." | |
116 | | | |
117 | \-"..." | |
118 | | |
119 +-message 2 | |
120 | | |
121 \-message 3 | |
122 | |
123 URL for reply posting: /foo/<message id>/reply | |
124 (posts to /foo/<message id> ) | |
125 | |
126 | |
127 Message Objects | |
128 --------------- | |
129 | |
130 { 'headers': {}, | |
131 'messages': [ list, of, children ], | |
132 'next': | |
133 'previous': | |
3
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
134 'parent': } |
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
135 |
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
136 |
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
137 Discussions -> Collaborative Documents |
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
138 -------------------------------------- |
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
139 |
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
140 discussions presents a strict hierachal document that can only append |
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
141 leaf nodes. Collaborative documents (e.g. a wiki) may also be |
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
142 hierachal, but additional functionality is implied: |
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
143 |
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
144 * the ability to edit nodes |
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
145 * the ability to merge nodes |
f09ba04b2e29
adding notes about -> collaborative documents
Jeff Hammel <k0scist@gmail.com>
parents:
2
diff
changeset
|
146 * the keeping of history (including all implied functionality of an VCS) |