Support for Capability items to be 'dynamic' #181
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added a new API to lib-imap which exposes functions for manipulating a capability list. This addition is the first step towards conditionally displaying capabilities. For example, displaying certain capabilities to the client only after TLS has been negotiated.
Updated imap-login to use the new capability list API from lib-imap which will allow for pre-login IMAP capabilities to be displayed conditionally.
This adds two new boolean fields: 'secured', and 'ssl_secured' to the imap client structure, these reflect the values of conn_secured and conn_ssl_secured respectively. This is a prerequisite to integrating the imap_capability_list APIs into imap because imap needs to distinguish between secured/tls/non-secured connections when determining whether conditional capabilities should be displayed or not.
Updated imap to use the new capability list API from lib-imap which will allow for post-login imap capabilities to be displayed conditionally. This ensures functionality of client_add_capability() does not change, and it introduces a new imap function client_get_capability() which is now used everywhere that client->capability_string was previously used.
|
Reopened from #86. Internal Jira: DOP-1362 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch converts the previous string-literal representation of the capabilities to a dynamic list of 'capability objects' each reflecting the capability word they intend to add along with flags that represent when the capability word is to be displayed (eg: varying states).
Upon a request for the capability string the list of capability objects is iterated and a capability string is dynamically built by appending each capability word if the conditions described in the flags of the capability object are met.
This patch provides full backwards compatibility for existing plugins that might have previously used client_add_capability as well as honors (and converts) existing string literal capability words into equivalent additions to the new list of capability objects.
Some examples of circumstances that can be specified when adding
new capabilities are:
The default operation is to show the capabaility word if at least
one of the circumstances is met, an additional flag provides the
ability to only show the capability word if exactly all of the
circumstances are met.
The API for adding capabilities now simply wraps the API for adding
entries to the capability list with the 'show always' flag set.
Retrieving the capability string is now a loop that iterates the list
of capability objects and evaluates whether each capability should be
added to the capability string based on the state of the current IMAP
session.