270
edits
MailNews:Better Faster IMAP Plan: Difference between revisions
→Implementation Plan
| Line 257: | Line 257: | ||
|} | |} | ||
<sup>1</sup> If and only if the selected folder is the source folder of the pending offline operation | <sup>1</sup> If and only if the selected folder is the source folder of the pending offline operation | ||
==== Requirements ==== | |||
# TB shall give two options to the user about how to download messages when a new account is created. Options are: | |||
## TB downloads all message headers and message bodies. The user has to wait until the downloads are completed. | |||
## TB downloads all message headers and starts downloading message bodies on background according to a predefined strategy. if the user selects a message on the list, TB should interrupt the current download without loosing the parts already downloaded, and should start downloading the selected message. | |||
# When new messages arrive, TB should download message headers immediately and should start downloading the bodies if the download queue is empty. If the download queue is busy, the decision can be made based on the active strategy (see possible strategies above) | |||
# Highest priority should be given always to the selected message. | |||
# All operations conducted on IMAP folders should be completed immediately, except copying/moving IMAP messages/folders to another server or account type. | |||
# All messages should be stored locally for offline and fast access. | |||
# Message header synchronization with the IMAP server shall be done silently, on background. | |||
# A new error notification mechanism is needed to accommodate new UI elements. | |||
==== Implementation Plan ==== | ==== Implementation Plan ==== | ||
* | |||
** | * Requirement #1.1 can be implemented by simply enabling AutoSyncOfflineStores option and putting the selected folder into offline mode. | ||
** | * Requirement #1.2 can be implemented with the help of the following new components: | ||
* | ** <b>Operation Queue</b>; Its main duty is to serialize access to imap protocol queue, and prioritize requested online operations. The components mentioned below are the consumer of this one. | ||
** | ** <b>Message download manager</b>; Main duties are to coordinate partial downloads, to make strategy-based decisions to prioritize messages. In the context of this component we need to implement PARTIAL FETCH commands in imap protocol level. The existing code fetches the mime structure of the message, and looks at the types of all the parts. If a message has parts TB doesn't know how to render inline (e.g., a .zip file, or a .doc or a .pdf), it fetches the body, and the parts TB knows how to display inline separately, and doesn't fetch the parts that TB can't render inline. We can definitely leverage this feature. | ||
** | ** <b>Operation playback manager</b>; To playback pending operations on the server and handling errors gracefully. In other word activating offline operation state machine when required. This component is partially implemented as part of <i>Offline operation playback</i> feature. | ||
** | * Requirement #1.3 is a matter of adding this option into mailnews.js | ||
* Error mechanism should be changed. Currently all imap errors are handled in imapserver. This code should be re-factored in order to make it work with new UI elements | * Requirement #2 same as #1.2 | ||
* Requirement #4 can be implemented by storing all operations locally, and playing them back using <i>Operation playback manager</i>. To store the operations locally TB can be put to the following states (''see Existing Behavior section''): | |||
*** <i>Copying/Moving an IMAP message</i>: one of the states 2, 8, 11, 12 | |||
*** <i>Selecting an IMAP message</i>: one of the states 2, 3, 4 | |||
*** <i>Tagging an IMAP message</i>: 2 or 4 | |||
*** <i>Selecting an IMAP folder</i>: 2 or 4 since header synchronization will be done on background - see following item | |||
** Common divider of these states is 2, in other word, it is possible to cover every scenario for this feature by handling every IMAP operation as TB is in offline state. | |||
* Requirement #5 will be handled when #1 and #2 are implemented. Only additional requirement for this feature is to running COMPACTING operation automatically on mbox files to keep them slim. | |||
* Requirement #6 requires creativity to keep the local database in sync with the server (including IDLE reponses). Currently TB creates fake keys for the headers generated during an offline operation, and it replaces them (the headers) during the folder update. Possible solutions are: | |||
** Solving the problem at UI level as David Bienvenu once suggested "One general approach would be to have the view ignore the removal of fake keys, and the addition of new keys, and instead tell it to replace one key with an other key. But that's a pretty half-baked thought at this point. An other approach would be tell the view about a set of message-ids that this is going to happen to - then, when it gets told about a delete of message with that message-id, it would ignore it, and when it gets told about the addition of a message with that same message id, it would go find the old message with that message id, and tweak that view entry to have the new message key." | |||
** Adding a new column to the local database to store the server keys when available. All operations will use local keys, server keys will be use only to sync with the server and to map header to its server counterpart. | |||
** Implementing a middle layer to map local keys to server keys. In other word, a component to map server data model to the local one. | |||
* Requirement #7 can be provided by implementing new UI elements. | |||
* One non-functional requirement is error handling. Error mechanism should be changed. Currently all imap errors are handled in imapserver. This code should be re-factored in order to make it work with new UI elements. | |||
==== Resources ==== | ==== Resources ==== | ||