-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
115 lines (101 loc) · 5.14 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
TODO
- References: field
In-Reply-To: is for e-mail
Maintenance
- More documentation, logging, and tests
NNTP
- Reread the information about encoding and look at the datasend function in
L<Net::Cmd>
- 3.1.1. Multi-line Data Blocks
<url:find:rfc3977.txt#line=399>
need to write helper to ensure responses comply
- XOVER, XHDR capabilities
- date time format
--- from RFC 3977
The date is specified as 6 or 8 digits in the format [xx]yymmdd,
where xx is the first two digits of the year (19-99), yy is the last
two digits of the year (00-99), mm is the month (01-12), and dd is
the day of the month (01-31). Clients SHOULD specify all four digits
of the year. If the first two digits of the year are not specified
(this is supported only for backward compatibility), the year is to
be taken from the current century if yy is smaller than or equal to
the current year, and the previous century otherwise.
The time is specified as 6 digits in the format hhmmss, where hh is
the hours in the 24-hour clock (00-23), mm is the minutes (00-59),
and ss is the seconds (00-60, to allow for leap seconds). The token
"GMT" specifies that the date and time are given in Coordinated
Universal Time [TF.686-1]; if it is omitted, then the date and time
are specified in the server's local timezone. Note that there is no
way of using the protocol specified in this document to establish the
server's local timezone.
Note that an empty list is a possible valid response and indicates
that there are no new newsgroups since that date-time.
Clients SHOULD make all queries using Coordinated Universal Time
(i.e., by including the "GMT" argument) when possible.
---
- "dot-stuffing"
NEWNEWS command
- Need to add a database role to retrieve the appropriate messages.
<url:find:rfc3977.txt#line=3566>
- All Date: fields should be in UTC. Write a test to ensure this.
Xref
- It may be possible for newsgroups to be in the Newsgroups: field, but not
carried on the server. The Xref: field would not be calculated for these. See
whether this is conforming to the spec. This would imply that groups must be
registered with the DB before any messages for these groups are added.
Updating messages and metadata
- Certain data sources have changing variant information that needs to be
updated and inserted into fields at a later time (e.g. moderation, score,
votes, etc.); this can not be done exactly at display time, but must be done
through updating the messages using a job queue in order to keep overview
database consistency. Note that this updating procedure does not have to only
apply to header fields — the entire body can be modified/replaced when a
message is requested. Filters? Use aspects? Re-register message and add a
X-Last-Updated: field?
The reason for this rather kludgy idea is that we need to serve headers,
possibly before the entire body is constructed. These changes can be aided by
subclassing L<NNTP::Message>.
- Polling and callbacks to update data with a scheduling mechanism that
provides for expiry
- Provide a way to update messages, possibly as an option to register_message
- Need to ensure that the article IDs are monotonically increasing, in the case
message deletion is added to the DB backend
- Possible solution to updating:
+ If the body is edited, a new reply should be created as a _reply_ the old
Message-ID. This will allow for readers that already read the old message
to see the changes.
+ If the metadata (moderation, etc.) changes, update the message header.
Database
- One could also use aspects to ask the plugins for more information for any of
the Database methods (e.g. get_newsgroup_desc) in the case there is none.
Provide sane defaults.
- These aspects can also be used in a multi-user environment to see if a given
user is authenticated to view a message or newsgroup.
+ It would be easier to provide just user-specific newsgroups (using the LIST
ACTIVE command). Having user-specific messages may mean dealing with many
articles that make using article ranges inefficient.
- Some of the NNTP commands are inefficient when dealing with database (i.e.
they get data from one command, then feed the results back to get other
data). One could specify more specific functions (that map directly to NNTP
commands) in roles that use the more general inefficient methods, but can be
overridden by the DB backend.
Control
- Out-of-band commands: interactions that do not fit into the NNTP model
+ commands (update, status, etc.)
+ notifications
- Proper daemon, init-script, etc.
Facebook
- More headers (application id, type (page, group, user), networks)
- Realtime update API <http://developers.facebook.com/docs/reference/api/realtime/>
- Events should have an iCalendar (.ics) attachment. {Actions: Accepting,
Declining}
Configuration
- change to Config::Model (libconfig-model-perl), supports writing back to
storage
- Bread::Board?
Other
- Support X-Face / Face headers
- Look into using Berkley DB and MLDBM
- Use transactions for DBI.
- Look at DBIx::Connector and DBIx::Class.
- Add type coercion to turn L<Mail::Message> into L<NNTP::Message>