paul@59 | 1 | Provide a means of reviewing and importing keys, most likely in conjunction
|
paul@59 | 2 | with actions provided by MoinMessage. A special parser might be the most
|
paul@59 | 3 | elegant way of displaying such content.
|
paul@59 | 4 |
|
paul@59 | 5 | (Make the macro aggregate feeds from a collection of sources, just like
|
paul@59 | 6 | EventAggregator. This is arguably superior to using URLs directly because the
|
paul@59 | 7 | sources are more easily managed and restrictions can also be placed on URLs
|
paul@59 | 8 | (in case someone deploys a resource that is too large for the wiki, for
|
paul@59 | 9 | example, causing the wiki to become unresponsive or unavailable).)
|
paul@59 | 10 |
|
paul@59 | 11 | (Provide improved containers and navigation for update content.)
|
paul@59 | 12 |
|
paul@59 | 13 | Consider integration with MoinMessage, possibly adding MoinShare compatibility
|
paul@59 | 14 | to posted content in MoinMessage (page regions would have a "moinshare"
|
paul@59 | 15 | attribute), and supporting MoinMessage mailbox inspection (for internal use)
|
paul@59 | 16 | and summaries (for external use) in MoinShare.
|
paul@59 | 17 |
|
paul@59 | 18 | Provide more efficient (indexed) access to message stores.
|
paul@59 | 19 |
|
paul@59 | 20 | Support packaging of wiki content into MoinMessages such that referenced
|
paul@59 | 21 | resources such as attachments are included in messages and accessible when
|
paul@59 | 22 | messages are displayed by the recipient, potentially without creating the
|
paul@59 | 23 | corresponding attachments in the recipient's system.
|
paul@59 | 24 |
|
paul@59 | 25 | Message body content is first parsed and attachments identified. References
|
paul@59 | 26 | to attachments are rewritten in the formatted output, and the attachments
|
paul@59 | 27 | themselves are added as additional parts to the message.
|
paul@59 | 28 |
|
paul@59 | 29 | Outgoing HTML content is parsed using a modified version of the
|
paul@59 | 30 | MoinMoin.support.htmlmarkup.HTMLSanitizer and attachment references are
|
paul@59 | 31 | rewritten.
|
paul@59 | 32 |
|
paul@59 | 33 | (For Moin content, a modified version of the
|
paul@59 | 34 | MoinMoin.formatter.text_html.Formatter is required, supporting
|
paul@59 | 35 | alternatives for the attachment-related methods. This is currently
|
paul@59 | 36 | provided in the MoinMessage SendMessage action.)
|
paul@59 | 37 |
|
paul@59 | 38 | Upon processing a message, references to external content are rewritten as
|
paul@59 | 39 | references to message parts involving links which invoke an action that can
|
paul@59 | 40 | retrieve message part content.
|
paul@59 | 41 |
|
paul@59 | 42 | (Incoming HTML content is parsed using a modified parser and attachment
|
paul@59 | 43 | references are rewritten.)
|
paul@59 | 44 |
|
paul@59 | 45 | For Moin content, attachment reference rewriting involves generating
|
paul@59 | 46 | special message-related links using another modified HTML formatter.
|
paul@59 | 47 |
|
paul@59 | 48 | (The message-related links are supported by an action which retrieves
|
paul@59 | 49 | attachments from stored messages.)
|
paul@59 | 50 |
|
paul@59 | 51 | Consider integration with EventAggregator since it already presents aggregated
|
paul@59 | 52 | data but does not yet support the retrieval of data from feeds.
|
paul@59 | 53 |
|
paul@59 | 54 | Support for iTIP in conjunction with MoinMessage would be useful.
|
paul@59 | 55 |
|
paul@59 | 56 | Support reading mailboxes from IMAP in order to access things like iTIP
|
paul@59 | 57 | requests.
|
paul@59 | 58 |
|
paul@59 | 59 | Evaluate the difference between cached but transient data provided by
|
paul@59 | 60 | resources as used in EventAggregator (where the vitality of the resource is
|
paul@59 | 61 | determined by its continued availability) and captured data provided by
|
paul@59 | 62 | messages as used by MoinMessage. Feeds could also be treated like inboxes and
|
paul@59 | 63 | the resources stored in a more permanent fashion.
|