1 Event Invitations and Attendance
2 --------------------------------
3
4 iTIP invitations (RFC 5546) could be supported. REQUEST method payloads are
5 effectively equivalent to plain iCalendar payloads; ADD method payloads are
6 similar to plain iCalendar payloads but augment previously received data,
7 whereas CANCEL method payloads remove or retract previously received data;
8 REFRESH method payloads are minimal requests for complete iCalendar payloads
9 to be sent in response. Other methods (REPLY, COUNTER, DECLINECOUNTER) update
10 the state of events according to attendance notifications.
11
12 For iTIP exchanges to work effectively, a mapping of the UID of each event to
13 the received information needs to be maintained. (An awareness of each
14 RECURRENCE-ID in an event is also useful where recurring events are being
15 handled.) Here, a form of index needs to be supported for efficient access via
16 event UIDs to event data. Other indexes might be supported for efficient
17 free/busy resource generation. Indexes could be supported using cache entries
18 just like the OpenID support (in MoinMoin.util.oid) uses them to track
19 associations.
20
21 The actual sending and receiving of iTIP messages needs to be supported by
22 other components such as MoinMessage. It might be interesting to support iTIP
23 notifications if events are changed directly on a wiki.
24
25 Navigation Controls
26 -------------------
27
28 The "New event" link should probably not be present when only remote events
29 are being aggregated by a calendar.
30
31 Improve the accessibility of controls by providing links with titles and
32 offering links as alternatives to pop-up elements.
33
34 Points in Time
35 --------------
36
37 Consider making dates convertible to timespans of the form (start of day,
38 start of next day).
39
40 Localised Keywords
41 ------------------
42
43 It should be possible to define events using localised equivalents of "start",
44 "end", "summary" and so on. To achieve this, the page language would be found
45 and regular expressions built to use the localised keywords, falling back on
46 the English keywords, would then search for event details.
47
48 Recurring Events
49 ----------------
50
51 Recurring event information from iCalendar sources should be considered in
52 order to avoid showing incomplete or incorrect event datetimes. Ultimately,
53 such information may need to be parsed and incorporated into the general event
54 recurrence processing.
55
56 Having events recur at certain intervals would potentially involve the
57 expansion of events to produce multiple instances within a specified period of
58 interest, and such expansion could occur after an event's details have been
59 read. Care would need to be taken in cases where no limits are placed on a
60 calendar: the expanded instances should not be allowed to recede into the past
61 and future indefinitely; where no other events exist to provide implicit
62 limits, some other default limits might be required to let the expansion
63 occur.
64
65 The description of recurring events could be based on the iCalendar
66 specification, although simpler schemes could be preferable. Recurring event
67 descriptions might start with "every" and then provide a time period ("day",
68 "week", "month", "year") for offsets from a specified date or time, perhaps
69 using qualifiers ("first", "second", "other", and so on), or instead provide a
70 more complete description using additional qualifiers that may override any
71 specified date or time for instances other than the primary occurrence. For
72 example, "every second Wednesday of every other month".
73
74 The resolution of each successive <recurrence> would need to be lower than
75 those it follows. Thus, "every second day of every second week..." would be
76 valid whereas "every second week of every second day..." would not.
77
78 Map Views
79 ---------
80
81 Other projections might be supported. This would be necessary for various
82 retrieved map images.
83
84 Dynamic images obtained from other sites or generated locally might provide some
85 enhancements to the map view. For example, a weather/radar image might show the
86 cloud or rain forecast either for the current situation or, if forecasts are
87 available, for the times of events shown.
88
89 Consider having day numbers down the side of a map view with highlighted days
90 indicating days having events, and with pop-up elements shown upon hovering over
91 each highlighted day.
92
93 To Do Items
94 -----------
95
96 Consider adding support for "to do" items. These might have time-related details
97 such as deadlines, but are more likely to have relationships with other items,
98 potentially forming a hierarchy of items.
99
100 Event Section Parser
101 --------------------
102
103 Events in page sections/regions could be presented using more sophisticated
104 methods and potentially be editable. To support direct editing, the parser
105 would provide a hidden form field indicating the location of the section in
106 the Wiki text, and the new event action would be enhanced to read existing
107 events from the indicated page region, populating the form fields with the
108 data found in the page.
109
110 UID Properties
111 --------------
112
113 Especially in the case of aggregation from multiple sources, the only reliable
114 way of avoiding repetition of the same events described in different places is
115 for authors to include a UID property identifying each event, using the same
116 value regardless of where the event is being published.
117
118 Formatting in iCalendar Output
119 ------------------------------
120
121 If there is a reasonably standard way of incorporating Wiki text in iCalendar
122 output alongside plain text, this would enable events aggregated from Wiki
123 sources to use Wiki text to describe things like the location and topics of an
124 event with links and other formatting that could then be reproduced in the
125 aggregating Wiki.
126
127 Remote Source Timeouts
128 ----------------------
129
130 Sometimes, network problems can cause delays in accessing remote sources. The
131 library should support either a timeout mechanism or asynchronous retrieval of
132 remote source data.