270
edits
MailNews:Better Faster IMAP Plan: Difference between revisions
Jump to navigation
Jump to search
→Emre: Proposal for Implementation
| Line 101: | Line 101: | ||
#* Shall rollback the UI operation if the command is not successful. | #* Shall rollback the UI operation if the command is not successful. | ||
#* Shall be smart enough to deal with event chaining, for example; Assume that Delete mode is "MoveToTrash", the user deletes 100 messages. TB moves the messages into the trash immediately and starts the operation on the background. Then the user moves 50th deleted message back into the INBOX and mark it as "Not Read" before the "move to trash" command is sent to the server. Proxy should be smart enough not to lose the message identifier, and change the command chain if necessary - moving a message into trash might change its identifier on the server, so the content of the pending command. | #* Shall be smart enough to deal with event chaining, for example; Assume that Delete mode is "MoveToTrash", the user deletes 100 messages. TB moves the messages into the trash immediately and starts the operation on the background. Then the user moves 50th deleted message back into the INBOX and mark it as "Not Read" before the "move to trash" command is sent to the server. Proxy should be smart enough not to lose the message identifier, and change the command chain if necessary - moving a message into trash might change its identifier on the server, so the content of the pending command. | ||
# | # Refactor Imap protocol layer to handle error cases gracefully, such as no-connection, server error, command execution error. Note: Put current threading model into consideration. When the user exceeds the number of cached-connections, all pending operations waiting for this session should be executed before recycling the thread. Thread recycling causes disconnection form the server which might cause an implicit EXPUNGE command on the server. (Estimation: ?) | ||
# Implement UI feedback mechanism (Estimation: ?) | # Implement UI feedback mechanism (Estimation: ?) | ||
| Line 123: | Line 123: | ||
**If yes, for which operations? Delete? Rename? Flag change? Tagging? | **If yes, for which operations? Delete? Rename? Flag change? Tagging? | ||
* How long should we store it? | * How long should we store it? | ||
* How to deal with | * How to deal with aged pending offline operations? | ||
* What kind of store we should use? Mork, Sqlite, text file | * What kind of store we should use? Mork, Sqlite, text file | ||
* Is security a concern - encryption? | * Is security a concern - encryption? | ||