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