EventAggregator

TO_DO.txt

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