113
edits
MailNews:Better Faster IMAP Plan: Difference between revisions
MailNews:Better Faster IMAP Plan (view source)
Revision as of 15:09, 8 December 2008
, 8 December 2008Corrected mime_parts_on_demand truth table logic
m (Corrected mime_parts_on_demand truth table logic) |
|||
| (16 intermediate revisions by 6 users not shown) | |||
| Line 14: | Line 14: | ||
** Until we have a failure in sending the Outbox doesn't offer much value, however once a failure occurs it needs to be high-visibility (clarkbw) | ** Until we have a failure in sending the Outbox doesn't offer much value, however once a failure occurs it needs to be high-visibility (clarkbw) | ||
** Do you suggest a virtual Outbox that will show up only there are pending messages? (emre) | ** Do you suggest a virtual Outbox that will show up only there are pending messages? (emre) | ||
*** Exactly, see [[Thunderbird:Folder Pane#Outbox]] | |||
* What UI do we present to allow users to override the auto-download of all message bodies? Is it per folder? Per account? Global? | * What UI do we present to allow users to override the auto-download of all message bodies? Is it per folder? Per account? Global? | ||
| Line 19: | Line 20: | ||
*** Concern 1: Change. Some people will be concerned about this change no matter what and will want an "off switch" or will complain loudly. | *** Concern 1: Change. Some people will be concerned about this change no matter what and will want an "off switch" or will complain loudly. | ||
*** Concern 2: Space. Other are probably concerned with space issues of auto-downloading, this requires some thought and is most likely the real underlying concern of #1. | *** Concern 2: Space. Other are probably concerned with space issues of auto-downloading, this requires some thought and is most likely the real underlying concern of #1. | ||
*** Concern 3: Policy. Some people may be under a policy that does not allow them to keep a local store of messages. (jaym) | |||
* Do we give the user feedback when the delete actually happens? (davida: IMO no, only when delete fails) | * Do we give the user feedback when the delete actually happens? (davida: IMO no, only when delete fails) | ||
| Line 32: | Line 34: | ||
** Draft Messages | ** Draft Messages | ||
'''Account Settings''' | |||
The goal of the account settings is to allow people to override the global offline preference on an account by account basis. | |||
<pre> | |||
+--------------------------------------------------------------------+ | |||
| Syncing & Disk Space | | |||
+--------------------------------------------------------------------+ | |||
| Message Synchronization | | |||
| [x] Keep all messages for this account on this computer | | |||
| ( Advanced... ) | | |||
| | | |||
+--------------------------------------------------------------------+ | |||
</pre> | |||
* Checkbox (defaults to global offline option) | |||
** When checked, changes all folders in the account to be sync'd | |||
** When unchecked changes all folders in account to not be sync'd | |||
* ( Advanced... ) | |||
** Opens folder selector for changing individual folder setup | |||
== Development Strategy == | == Development Strategy == | ||
| Line 170: | Line 191: | ||
=== 2) Preemptive/Automatic Message Download === | === 2) Preemptive/Automatic Message Download === | ||
[Emre May 30th, 2008] {{bug| 436615}} has been filed. | [Emre May 30th, 2008] {{bug|436615}} has been filed. Marked FIXED 2008-09-17 17:01:35 PDT. | ||
==== Existing Behavior ==== | ==== Existing Behavior ==== | ||
| Line 211: | Line 232: | ||
| Fetch message from the server || <center>X</center> || <center>-</center> || <center>X</center> || <center>-</center> | | Fetch message from the server || <center>X</center> || <center>-</center> || <center>X</center> || <center>-</center> | ||
|- | |- | ||
| Get local copy if available|| || <center>X</center> || | | Get local copy if available|| || <center>X</center> || <center>X</center> || <center>X</center> | ||
|- | |- | ||
| Store locally in the folder's <i>mbox</i> || || || <center>X</center> || | | Store locally in the folder's <i>mbox</i> || || || <center>X<sup>1</sup></center> || | ||
|- | |- | ||
|} | |} | ||
*<sup>1</sup> Depending on preferences message '''''is not''''' stored locally if non-inline MIME parts (e.g. attachments) size > mime_parts_on_demand_threshold (default ~30KB) '''OR''' total message size > limit_offline_message_size (default off). See Advanced and Offline & Diskspace preferences. | |||
| Line 255: | Line 277: | ||
Source and Destination folders are offline, autosync_offline_stores is set to true by default, pseudo offline is enabled: | Source and Destination folders are offline, autosync_offline_stores is set to true by default, pseudo offline is enabled: | ||
* When a folder is selected the first time, TB fetches all message keys (a.k.a Messages unique identifier values) belong to this folder from the server (using <tag> UID fetch 1:* (FLAGS) imap command). It keeps the mutual keys intact, adds new keys into the local database, and removes the non-existing ones. Once this operation | * When a folder is selected the first time, TB fetches all message keys (a.k.a Messages unique identifier values) belong to this folder from the server (using <tag> UID fetch 1:* (FLAGS) imap command). It keeps the mutual keys intact, adds new keys into the local database, and removes the non-existing ones. Once this operation is completed, it fetches the headers and message bodies belong to the new keys (I think all headers first, bodies later, not sure). Finally, it stores the next UID value to determine whether any messages have been delivered to the mailbox next time it is selected. | ||
* If another folder is selected before all message bodies are downloaded, it stops downloading, switches to the other folder and starts the same process on this newly selected folder. Once this is completed, it resumes the download of the message bodies belong to the previously selected folder. A progress bar appears at the bottom right side of the window, but it doesn't show any progress. | * If another folder is selected before all message bodies are downloaded, it stops downloading, switches to the other folder and starts the same process on this newly selected folder. Once this is completed, it resumes the download of the message bodies belong to the previously selected folder. A progress bar appears at the bottom right side of the window, but it doesn't show any progress. | ||
| Line 306: | Line 328: | ||
|} | |} | ||
==== Implementation Plan #1==== | ==== Implementation Plan #1 (Low hanging fruit approach)==== | ||
* Requirement #1.1 can be implemented by simply enabling AutoSyncOfflineStores option and putting the selected folder into offline mode. | * Requirement #1.1 can be implemented by simply enabling AutoSyncOfflineStores option and putting the selected folder into offline mode. | ||
* Requirement #1.2 - skip | * Requirement #1.2 - skip | ||
| Line 315: | Line 337: | ||
* Requirement #7 - skip | * Requirement #7 - skip | ||
==== Implementation Plan #2==== | ==== Implementation Plan #2 (Ideal)==== | ||
* Requirement #1.1 can be implemented by simply enabling AutoSyncOfflineStores option and putting the selected folder into offline mode - adding this option into mailnews.js file. | * Requirement #1.1 can be implemented by simply enabling AutoSyncOfflineStores option and putting the selected folder into offline mode - adding this option into mailnews.js file. | ||
| Line 339: | Line 361: | ||
* 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. | * 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. | ||
==== Tasks ==== | ==== Tasks for #1==== | ||
* Playback Manager - ''partially implemented'' (?, estimate: ?) | |||
** Activate playback state machine | |||
** Handle errors | |||
** Group playback request | |||
* Change existing workflow to fetch messages from the local store | |||
* Implement automatic compacting | |||
==== Tasks for #2==== | |||
* Priority Queue implementation (?, estimate: ?) | * Priority Queue implementation (?, estimate: ?) | ||
* Message Download Manager implementation | * Message Download Manager implementation | ||
| Line 370: | Line 400: | ||
==== Decisions to make==== | ==== Decisions to make==== | ||
* | * Which implementation to go? | ||
* If we go with #2, how we keep the local data model and server data model in sync? | |||
** [emre] I prefer 4th approach. I can't say I totally understand the overall system design yet but it seems doable. Here is the rationale: | ** [emre] I prefer 4th approach. I can't say I totally understand the overall system design yet but it seems doable. Here is the rationale: | ||
*** It doesn't require any change of the database schema | *** It doesn't require any change of the database schema | ||