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