1 Navigation Controls
2 -------------------
3
4 Without a calendar start, end and calendar name, the list view still shows
5 navigation controls. Also, links to other views from the day view can override
6 the default "all events" limits, which is not necessarily beneficial.
7
8 The "New event" link should probably not be present when only remote events
9 are being aggregated by a calendar.
10
11 Points in Time
12 --------------
13
14 Events which have identical start and end times might be represented by
15 building a calendar scale that distinguishes between times acting as start
16 times and times acting as end times. (The iCalendar specification appears to
17 state that events without end dates/times are actually points in time, but
18 this potentially conflicts with the expectation that merely specifying a start
19 date or time produces an event with an undefined end point or a "common sense"
20 end point.)
21
22 Consider making dates convertible to timespans of the form (start of day,
23 start of next day).
24
25 Location Selection
26 ------------------
27
28 A menu of locations derived from the EventLocationsDict could be shown by the
29 new event action.
30
31 Localised Keywords
32 ------------------
33
34 It should be possible to define events using localised equivalents of "start",
35 "end", "summary" and so on. To achieve this, the page language would be found
36 and regular expressions built to use the localised keywords, falling back on
37 the English keywords, would then search for event details.
38
39 Recurring Events
40 ----------------
41
42 Recurring event information from iCalendar sources should be considered in
43 order to avoid showing incomplete or incorrect event datetimes. Ultimately,
44 such information may need to be parsed and incorporated into the general event
45 recurrence processing.
46
47 Having events recur at certain intervals would potentially involve the
48 expansion of events to produce multiple instances within a specified period of
49 interest, and such expansion could occur after an event's details have been
50 read. Care would need to be taken in cases where no limits are placed on a
51 calendar: the expanded instances should not be allowed to recede into the past
52 and future indefinitely; where no other events exist to provide implicit
53 limits, some other default limits might be required to let the expansion
54 occur.
55
56 The description of recurring events could be based on the iCalendar
57 specification, although simpler schemes could be preferable. Recurring event
58 descriptions might start with "every" and then provide a time period ("day",
59 "week", "month", "year") for offsets from a specified date or time, perhaps
60 using qualifiers ("first", "second", "other", and so on), or instead provide a
61 more complete description using additional qualifiers that may override any
62 specified date or time for instances other than the primary occurrence. For
63 example, "every second Wednesday of every other month".
64
65 Possible grammar:
66
67 <recurrence> [ of <recurrence> ]...
68 [ from <datetime> ]
69 [ until <datetime> ]
70
71 recurrence = every [ <qualifier> ] <interval>
72 interval = second | minute | hour | day | <weekday> | week | month | year
73
74 The resolution of each successive <recurrence> must be lower than those it
75 follows. Thus, "every second day of every second week..." is valid whereas
76 "every second week of every second day..." is 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 could be described using a Wiki section, potentially retaining the
104 definition list syntax for consistency with the current method of describing
105 events:
106
107 {{{#!event
108 Start:: 2011-06-07
109 End:: 2011-06-07
110 Summary:: Event inside a section
111 }}}
112
113 Such events could then be presented using more sophisticated methods and
114 potentially be editable. To support direct editing, the parser would provide
115 a hidden form field indicating the location of the section in the Wiki text,
116 and the new event action would be enhanced to read existing events from the
117 indicated page region, populating the form fields with the data found in the
118 page.
119
120 Enhance the linkToEvent method on Event instances so that event sections can
121 provide anchors for events in Wiki pages.
122
123 UID Properties
124 --------------
125
126 Especially in the case of aggregation from multiple sources, the only reliable
127 way of avoiding repetition of the same events described in different places is
128 for authors to include a UID property identifying each event, using the same
129 value regardless of where the event is being published.
130
131 Remote Source Timeouts
132 ----------------------
133
134 Sometimes, network problems can cause delays in accessing remote sources. The
135 library should support either a timeout mechanism or asynchronous retrieval of
136 remote source data.