1 iCalendar Serialisation
2 -----------------------
3
4 The vContent serialisation should probably be used instead of the existing
5 code.
6
7 Navigation Controls
8 -------------------
9
10 The "New event" link should probably not be present when only remote events
11 are being aggregated by a calendar.
12
13 Points in Time
14 --------------
15
16 Make events with identical start and end times appear in the day view,
17 potentially using the approach given below.
18
19 Events which have identical start and end times might be represented by
20 building a calendar scale that distinguishes between times acting as start
21 times and times acting as end times. (The iCalendar specification appears to
22 state that events without end dates/times are actually points in time, but
23 this potentially conflicts with the expectation that merely specifying a start
24 date or time produces an event with an undefined end point or a "common sense"
25 end point.)
26
27 Consider making dates convertible to timespans of the form (start of day,
28 start of next day).
29
30 Localised Keywords
31 ------------------
32
33 It should be possible to define events using localised equivalents of "start",
34 "end", "summary" and so on. To achieve this, the page language would be found
35 and regular expressions built to use the localised keywords, falling back on
36 the English keywords, would then search for event details.
37
38 Recurring Events
39 ----------------
40
41 Recurring event information from iCalendar sources should be considered in
42 order to avoid showing incomplete or incorrect event datetimes. Ultimately,
43 such information may need to be parsed and incorporated into the general event
44 recurrence processing.
45
46 Having events recur at certain intervals would potentially involve the
47 expansion of events to produce multiple instances within a specified period of
48 interest, and such expansion could occur after an event's details have been
49 read. Care would need to be taken in cases where no limits are placed on a
50 calendar: the expanded instances should not be allowed to recede into the past
51 and future indefinitely; where no other events exist to provide implicit
52 limits, some other default limits might be required to let the expansion
53 occur.
54
55 The description of recurring events could be based on the iCalendar
56 specification, although simpler schemes could be preferable. Recurring event
57 descriptions might start with "every" and then provide a time period ("day",
58 "week", "month", "year") for offsets from a specified date or time, perhaps
59 using qualifiers ("first", "second", "other", and so on), or instead provide a
60 more complete description using additional qualifiers that may override any
61 specified date or time for instances other than the primary occurrence. For
62 example, "every second Wednesday of every other month".
63
64 Possible grammar:
65
66 <recurrence> [ of <recurrence> ]...
67 [ from <datetime> ]
68 [ until <datetime> ]
69
70 recurrence = every [ <qualifier> ] <interval>
71 interval = second | minute | hour | day | <weekday> | week | month | year
72
73 The resolution of each successive <recurrence> must be lower than those it
74 follows. Thus, "every second day of every second week..." is valid whereas
75 "every second week of every second day..." is not.
76
77 Map Views
78 ---------
79
80 Other projections might be supported. This would be necessary for various
81 retrieved map images.
82
83 Dynamic images obtained from other sites or generated locally might provide some
84 enhancements to the map view. For example, a weather/radar image might show the
85 cloud or rain forecast either for the current situation or, if forecasts are
86 available, for the times of events shown.
87
88 Consider having day numbers down the side of a map view with highlighted days
89 indicating days having events, and with pop-up elements shown upon hovering over
90 each highlighted day.
91
92 To Do Items
93 -----------
94
95 Consider adding support for "to do" items. These might have time-related details
96 such as deadlines, but are more likely to have relationships with other items,
97 potentially forming a hierarchy of items.
98
99 Event Section Parser
100 --------------------
101
102 Events in page sections/regions could be presented using more sophisticated
103 methods and potentially be editable. To support direct editing, the parser
104 would provide a hidden form field indicating the location of the section in
105 the Wiki text, and the new event action would be enhanced to read existing
106 events from the indicated page region, populating the form fields with the
107 data found in the page.
108
109 UID Properties
110 --------------
111
112 Especially in the case of aggregation from multiple sources, the only reliable
113 way of avoiding repetition of the same events described in different places is
114 for authors to include a UID property identifying each event, using the same
115 value regardless of where the event is being published.
116
117 Formatting in iCalendar Output
118 ------------------------------
119
120 If there is a reasonably standard way of incorporating Wiki text in iCalendar
121 output alongside plain text, this would enable events aggregated from Wiki
122 sources to use Wiki text to describe things like the location and topics of an
123 event with links and other formatting that could then be reproduced in the
124 aggregating Wiki.
125
126 Remote Source Timeouts
127 ----------------------
128
129 Sometimes, network problems can cause delays in accessing remote sources. The
130 library should support either a timeout mechanism or asynchronous retrieval of
131 remote source data.