-
Notifications
You must be signed in to change notification settings - Fork 0
Implementation of missing IMAP features and extensions
27th April – 9th May (Community bonding period): Will use this time to get to know as much as I can about the K-9 community, development processes, expectations from my project, and most of all, maximize my familiarity with the codebase, since most of my project work involves building upon or fixing existing, but broken/incomplete features of IMAP.
Prior Appointments: Will be unavailable from 16th May – 28th May on account of end-term examinations at my university.
Current State: Creation of some special mailboxes (Trash/Drafts etc) is supported, but only internally by the K-9 Mail app. Deletion/renaming is unimplemented.
Description: This feature aims to enable the K-9 Mail user to be able to view, create, modify and delete mailboxes which are accessible to him.
Deliverables: An implementation of the CREATE, DELETE, RENAME commands and handling of their responses (which includes mirroring any changes made to the server in the LocalStore). Creation of a complementing UI for the user to access these features.
Timeline: 10th May – 31st May (see Prior Appointments)
Current State: In the default behavior, all folders are displayed, but a preference toggle setting exists, which enables display of only those folders which a user has subscribed to on the server. However, there is no method to edit these subscriptions.
Description: The SUBSCRIBE/UNSUBSCRIBE command lets you maintain a list of folders on the server. This list may be retrieved by using the LSUB command.
Deliverables: An implementation of the SUBSCRIBE/UNSUBSCRIBE commands and handling of their responses (which includes mirroring any changes made to the server in the LocalStore). Creation of a complementing UI for the user to access these features.
Timeline: 1st June – 5th June
Current State: UIDVALIDITY and any changes in its value across sessions is ignored completely.
Description: The UIDVALIDITY value is a key element which points to the validity of UIDs of messages in a folder. UIDVALIDITY remains same for a single session, but may change between sessions. If UIDVALIDITY is the same for this session as it was in the previous session, UIDs must not have changed. If UIDVALIDITY has changed, then all UIDs must have changed.
Deliverables: Store UIDVALIDITY value for each session in the LocalStore. A message can be uniquely identified, forever, by using a combination of (folder name + UIDVALIDITY + UID). If UIDVALIDITY has changed, then request (UID, Message-ID) from the server for all messages in the current folder. Use the Message-ID attribute to map the new UIDs to existing messages from the LocalStore. If a unique match is found, store new UID and flags. If more than one matches are found (or none), then redownload and sync those messages. Delete the ones for which no matches were found.
Timeline: 6th June – 20th June
Current State: The current parser implementation does not check for context, and handles all responses similarly, by calling a series of long (and some recursive) methods over each response.
Description: Server responses can be classified into multiple categories: status responses, server/mailbox status responses, mailbox size, message status and command continuation requests. Each category of responses have a well defined response type and therefore need specialized, context-sensitive response parsers for optimal performance.
Deliverables: Status responses (OK, NO, BAD, PREAUTH, BYE) always contain resp-text tokens, and therefore need not be passed through above mentioned methods. A separate handler needs to be written to handle the resp-text tokens. A few other responses such as EXISTS, RECENT, EXPUNGE have empty token lists, and should be appropriately handled.
Timeline: 21st June – 30th June
Current State: The current implementation of EXPUNGE does not take into account messages that may have been deleted by another client in between sessions and expunges all messages flagged with ‘\Deleted’. Also, since the result of an APPEND/COPY command from a server which does not support UIDPLUS does not contain the new UIDs of the copied messages, an additional sync is required just to bring the local UIDs of effected messages upto date.
Description: The UIDPLUS extension defines the UID EXPUNGE command, which by imposing a restriction of a range of UIDs over the EXPUNGE command, ensures that only those messages are expunged which were deleted by this client (and leaves those deleted by other clients unaffected). Additionally, a server supporting UIDPLUS returns UID ranges as APPENDUID/COPYUID responses to APPEND/COPY commands respectively. If a mailbox does not support persistent UIDs, a UIDNOTSTICKY response is returned when the mailbox is selected.
Deliverables: Implementation of the UID EXPUNGE command, as an optional feature, via a preference toggle setting (minimal UI changes required). Support for handling the APPENDUID, COPYUID and UIDNOTSTICKY responses and making appropriate changes in the LocalStore (effectively saving the additional sync as mentioned above).
Timeline: 1st July – 12th July
Current State: A specially loaded SEARCH command is used internally for tasks such as fetching the highest UID in a mailbox, getting a count of flagged/unseen messages in a folder. The search button is mapped to a search of the LocalStore only, which does not reflect any changes made by another client or on the server side between sessions/commands, or any unsynced messages in general.
Description/Deliverables: Creation of an advanced search UI, which supports searching both locally as well as on the server side, as an additional menu option, with the search button behavior unchanged. Laying down the ground work for formation of server side search queries using the SEARCH command, and intergrating both local and server search mechanisms to work together.
Timeline: 13th July – 22nd July
Current State: If the server response to a command is empty or non-OK, the current implementation tries to execute the command again, expecting a different response from the server. This clogs up the pending actions queue.
Description: Some IMAP commands will always fail in a particular situation. For example, trying to delete a message that was expunged by some other client in between sessions will always fail as the message no longer exists. Such failing commands are tagged with either a NO or BAD response token.
Deliverables: Modify the current implementation so that any non-OK response is marked as a permanent exception, and is never tried again (unless requested by the user explicitly). If possible, lay out the ground work for an error reporting framework which uses the resp-text from above mentioned responses to report exceptions to the user and demand action.
Timeline: 23rd July – 26th July
Current State: The current implementation of namespaces only handles the personal (default) namespace of the user. If there exists a non-default blank namespace “”, there is currently no way to select it, since if the namespace field is empty, K-9 uses the default namespace.
Description: An authenticated user may have access to 3 separate categories of namespaces: his personal namespace, other user’s namespaces or common, shared namespaces.
Deliverables: Implementation of the NAMESPACE command, which returns the listing of all namespaces that the server wishes to expose to the client. Creation of appropriate UI to present the user with a multi-select list of namespaces from which he can choose which ones to display/use. Also, allow interaction between folders from different namespaces in the same manner that interaction occurs between folders from the same namespace.
Timeline: 27th July – 8th August
9th August – 22nd August: Finalize/polish all contributions, complete documentation, integration and system testing, fix any bugs that appear during testing and finally submit any uncommitted code.
The timeline sketched out here is based on my estimations and interactions with existing contributors in the community, and thus are only approximate. Due to the number of sub-tasks (most of which are independent of each other) the time ranges for a few are bound to bleed into each other.