1 Points in Time
2 --------------
3
4 Events which have identical start and end times might be represented by
5 building a calendar scale that distinguishes between times acting as start
6 times and times acting as end times.
7
8 Consider making dates convertible to timespans of the form (start of day,
9 start of next day).
10
11 GriCal and External Aggregation
12 -------------------------------
13
14 Make URL parameterisation robust enough to prevent arbitrary URL fragment
15 insertion.
16
17 Support a linkToEvent method on Event instances, possibly just delegating to
18 linkToPage for Wiki events (although event sections could provide anchors for
19 events in Wiki pages). Calendar events would provide their own URL property.
20
21 Support caching and proper encoding detection. Response metadata could be
22 inspected, defaulting to UTF-8 if necessary.
23
24 Support navigation where the full extent of external events cannot be
25 detected.
26
27 Localised Keywords
28 ------------------
29
30 It should be possible to define events using localised equivalents of "start",
31 "end", "summary" and so on. To achieve this, the page language would be found
32 and regular expressions built to use the localised keywords, falling back on
33 the English keywords, would then search for event details.
34
35 Recurring Events
36 ----------------
37
38 Having events recur at certain intervals would potentially involve the
39 expansion of events to produce multiple instances within a specified period of
40 interest, and such expansion could occur after an event's details have been
41 read. Care would need to be taken in cases where no limits are placed on a
42 calendar: the expanded instances should not be allowed to recede into the past
43 and future indefinitely; where no other events exist to provide implicit
44 limits, some other default limits might be required to let the expansion
45 occur.
46
47 The description of recurring events could be based on the iCalendar
48 specification, although simpler schemes could be preferable. Recurring event
49 descriptions might start with "every" and then provide a time period ("day",
50 "week", "month", "year") for offsets from a specified date or time, perhaps
51 using qualifiers ("first", "second", "other", and so on), or instead provide a
52 more complete description using additional qualifiers that may override any
53 specified date or time for instances other than the primary occurrence. For
54 example, "every second Wednesday of every other month".
55
56 Map Views
57 ---------
58
59 Explicit latitude and longitude values (such as the iCalendar GEO property)
60 could be supported.
61
62 Other projections might be supported. This would be necessary for various
63 retrieved map images.
64
65 Dynamic images obtained from other sites or generated locally might provide some
66 enhancements to the map view. For example, a weather/radar image might show the
67 cloud or rain forecast either for the current situation or, if forecasts are
68 available, for the times of events shown.
69
70 Consider having day numbers down the side of a map view with highlighted days
71 indicating days having events, and with pop-up elements shown upon hovering over
72 each highlighted day.
73
74 To Do Items
75 -----------
76
77 Consider adding support for "to do" items. These might have time-related details
78 such as deadlines, but are more likely to have relationships with other items,
79 potentially forming a hierarchy of items.
80
81 Event Section Parser
82 --------------------
83
84 Events could be described using a Wiki section, potentially retaining the
85 definition list syntax for consistency with the current method of describing
86 events:
87
88 {{{#!event
89 Start:: 2011-06-07
90 End:: 2011-06-07
91 Summary:: Event inside a section
92 }}}
93
94 Such events could then be presented using more sophisticated methods and
95 potentially be editable. To support direct editing, the parser would provide
96 a hidden form field indicating the location of the section in the Wiki text,
97 and the new event action would be enhanced to read existing events from the
98 indicated page region, populating the form fields with the data found in the
99 page.