paul@420 | 1 | Event Invitations and Attendance
|
paul@420 | 2 | --------------------------------
|
paul@420 | 3 |
|
paul@420 | 4 | iTIP invitations (RFC 5546) could be supported. REQUEST method payloads are
|
paul@420 | 5 | effectively equivalent to plain iCalendar payloads; ADD method payloads are
|
paul@420 | 6 | similar to plain iCalendar payloads but augment previously received data,
|
paul@420 | 7 | whereas CANCEL method payloads remove or retract previously received data;
|
paul@420 | 8 | REFRESH method payloads are minimal requests for complete iCalendar payloads
|
paul@420 | 9 | to be sent in response. Other methods (REPLY, COUNTER, DECLINECOUNTER) update
|
paul@420 | 10 | the state of events according to attendance notifications.
|
paul@420 | 11 |
|
paul@420 | 12 | For iTIP exchanges to work effectively, a mapping of the UID of each event to
|
paul@420 | 13 | the received information needs to be maintained. (An awareness of each
|
paul@420 | 14 | RECURRENCE-ID in an event is also useful where recurring events are being
|
paul@420 | 15 | handled.) Here, a form of index needs to be supported for efficient access via
|
paul@420 | 16 | event UIDs to event data. Other indexes might be supported for efficient
|
paul@428 | 17 | free/busy resource generation. Indexes could be supported using cache entries
|
paul@428 | 18 | just like the OpenID support (in MoinMoin.util.oid) uses them to track
|
paul@428 | 19 | associations.
|
paul@420 | 20 |
|
paul@420 | 21 | The actual sending and receiving of iTIP messages needs to be supported by
|
paul@420 | 22 | other components such as MoinMessage. It might be interesting to support iTIP
|
paul@420 | 23 | notifications if events are changed directly on a wiki.
|
paul@420 | 24 |
|
paul@290 | 25 | Navigation Controls
|
paul@290 | 26 | -------------------
|
paul@290 | 27 |
|
paul@290 | 28 | The "New event" link should probably not be present when only remote events
|
paul@290 | 29 | are being aggregated by a calendar.
|
paul@290 | 30 |
|
paul@368 | 31 | Improve the accessibility of controls by providing links with titles and
|
paul@368 | 32 | offering links as alternatives to pop-up elements.
|
paul@368 | 33 |
|
paul@218 | 34 | Points in Time
|
paul@218 | 35 | --------------
|
paul@218 | 36 |
|
paul@218 | 37 | Consider making dates convertible to timespans of the form (start of day,
|
paul@218 | 38 | start of next day).
|
paul@218 | 39 |
|
paul@211 | 40 | Localised Keywords
|
paul@211 | 41 | ------------------
|
paul@211 | 42 |
|
paul@211 | 43 | It should be possible to define events using localised equivalents of "start",
|
paul@211 | 44 | "end", "summary" and so on. To achieve this, the page language would be found
|
paul@211 | 45 | and regular expressions built to use the localised keywords, falling back on
|
paul@211 | 46 | the English keywords, would then search for event details.
|
paul@211 | 47 |
|
paul@211 | 48 | Recurring Events
|
paul@211 | 49 | ----------------
|
paul@211 | 50 |
|
paul@232 | 51 | Recurring event information from iCalendar sources should be considered in
|
paul@232 | 52 | order to avoid showing incomplete or incorrect event datetimes. Ultimately,
|
paul@232 | 53 | such information may need to be parsed and incorporated into the general event
|
paul@232 | 54 | recurrence processing.
|
paul@232 | 55 |
|
paul@211 | 56 | Having events recur at certain intervals would potentially involve the
|
paul@211 | 57 | expansion of events to produce multiple instances within a specified period of
|
paul@211 | 58 | interest, and such expansion could occur after an event's details have been
|
paul@211 | 59 | read. Care would need to be taken in cases where no limits are placed on a
|
paul@211 | 60 | calendar: the expanded instances should not be allowed to recede into the past
|
paul@211 | 61 | and future indefinitely; where no other events exist to provide implicit
|
paul@211 | 62 | limits, some other default limits might be required to let the expansion
|
paul@211 | 63 | occur.
|
paul@211 | 64 |
|
paul@211 | 65 | The description of recurring events could be based on the iCalendar
|
paul@211 | 66 | specification, although simpler schemes could be preferable. Recurring event
|
paul@211 | 67 | descriptions might start with "every" and then provide a time period ("day",
|
paul@211 | 68 | "week", "month", "year") for offsets from a specified date or time, perhaps
|
paul@211 | 69 | using qualifiers ("first", "second", "other", and so on), or instead provide a
|
paul@211 | 70 | more complete description using additional qualifiers that may override any
|
paul@211 | 71 | specified date or time for instances other than the primary occurrence. For
|
paul@211 | 72 | example, "every second Wednesday of every other month".
|
paul@211 | 73 |
|
paul@356 | 74 | The resolution of each successive <recurrence> would need to be lower than
|
paul@356 | 75 | those it follows. Thus, "every second day of every second week..." would be
|
paul@356 | 76 | valid whereas "every second week of every second day..." would not.
|
paul@227 | 77 |
|
paul@204 | 78 | Map Views
|
paul@204 | 79 | ---------
|
paul@204 | 80 |
|
paul@218 | 81 | Other projections might be supported. This would be necessary for various
|
paul@218 | 82 | retrieved map images.
|
paul@218 | 83 |
|
paul@204 | 84 | Dynamic images obtained from other sites or generated locally might provide some
|
paul@204 | 85 | enhancements to the map view. For example, a weather/radar image might show the
|
paul@204 | 86 | cloud or rain forecast either for the current situation or, if forecasts are
|
paul@204 | 87 | available, for the times of events shown.
|
paul@204 | 88 |
|
paul@204 | 89 | Consider having day numbers down the side of a map view with highlighted days
|
paul@204 | 90 | indicating days having events, and with pop-up elements shown upon hovering over
|
paul@204 | 91 | each highlighted day.
|
paul@204 | 92 |
|
paul@204 | 93 | To Do Items
|
paul@204 | 94 | -----------
|
paul@204 | 95 |
|
paul@204 | 96 | Consider adding support for "to do" items. These might have time-related details
|
paul@204 | 97 | such as deadlines, but are more likely to have relationships with other items,
|
paul@204 | 98 | potentially forming a hierarchy of items.
|
paul@204 | 99 |
|
paul@204 | 100 | Event Section Parser
|
paul@204 | 101 | --------------------
|
paul@204 | 102 |
|
paul@336 | 103 | Events in page sections/regions could be presented using more sophisticated
|
paul@336 | 104 | methods and potentially be editable. To support direct editing, the parser
|
paul@336 | 105 | would provide a hidden form field indicating the location of the section in
|
paul@336 | 106 | the Wiki text, and the new event action would be enhanced to read existing
|
paul@336 | 107 | events from the indicated page region, populating the form fields with the
|
paul@336 | 108 | data found in the page.
|
paul@242 | 109 |
|
paul@242 | 110 | UID Properties
|
paul@242 | 111 | --------------
|
paul@242 | 112 |
|
paul@242 | 113 | Especially in the case of aggregation from multiple sources, the only reliable
|
paul@242 | 114 | way of avoiding repetition of the same events described in different places is
|
paul@242 | 115 | for authors to include a UID property identifying each event, using the same
|
paul@242 | 116 | value regardless of where the event is being published.
|
paul@265 | 117 |
|
paul@292 | 118 | Formatting in iCalendar Output
|
paul@292 | 119 | ------------------------------
|
paul@292 | 120 |
|
paul@292 | 121 | If there is a reasonably standard way of incorporating Wiki text in iCalendar
|
paul@292 | 122 | output alongside plain text, this would enable events aggregated from Wiki
|
paul@292 | 123 | sources to use Wiki text to describe things like the location and topics of an
|
paul@292 | 124 | event with links and other formatting that could then be reproduced in the
|
paul@292 | 125 | aggregating Wiki.
|
paul@292 | 126 |
|
paul@265 | 127 | Remote Source Timeouts
|
paul@265 | 128 | ----------------------
|
paul@265 | 129 |
|
paul@265 | 130 | Sometimes, network problems can cause delays in accessing remote sources. The
|
paul@265 | 131 | library should support either a timeout mechanism or asynchronous retrieval of
|
paul@265 | 132 | remote source data.
|