Design In this part, we'll discuss the design of various parts of modest. We'll not go into the details of various APIs in this chapter. Please consult the documentation generated from the source code (gtk-doc) for that. Configuration Configuration is the part of modest that deals with storing all settings. While the design allows for alternative implementations, currently only GConf is supported as a backend. All dealing with configuration is done with the ModestConf-class. It is declared in modest-conf.h, and the GConf-based implementation in modest-conf.c. As said, there could be different implementations -- nothing GConf-specific is visible in the ModestConf-API. Account Management Account Management is the part of modest that deals with the setting related to sending and receiving of e-mail. We will follow the libcamel-convention of using the term store for an e-mail storage/retrieval server, and a transport for a server that transports mail to its destination. In practice, the following types are available: stores: POP and IMAP; transports: sendmail and SMTP. Definitions An account is a named entity consisting of a store and a transport. Note: For our mobile use-cases, the transport cannot be a static entity, but may depend on the network connection. That is however not part of Account Management, so not discussed here A server account is account describing the connection with a specific server. Server accounts come in two type: A transport describes the connection information (servername, username, password etc.) for a transport server; A store describes the connection information for a store server; Code The functions to deal with account and server accounts are located in ModestAccountMgr, ie. in modest-account-mgr.[ch]. There function to add specific values for both, to list the available ones, etc. Please refer to the source code documentation for details. Location in configuration database Accounts can be found in /apps/modest/accounts, while server accounts can be found in /app/modest/server_accounts. The following image show an account accountstest with server accounts mystore and mytransport. For each of the stores, there are number of parameters specified: hostname - the place where the server resides; username - the username; password - the password; proto - the protocal for communication with this server - for now these are the following valid values (literal strings): sendmail; smtp; pop imap. In modest-proto.[ch] there are various functions to check whether something is a valid protocol, and whether it is a transport of a store. Note that server accounts and accounts are relatively independent. While accounts refer to two server accounts, these server accounts can be used by other accounts as well. The reason two keep accounts and server accounts separately, is a bit of flexibility. In mobile use-cases, quite often it's desirable to use a network-specific smtp-server. The chosen structure makes it easy to iterate over all smtp-servers and find the right one. Account Management and Tinymail Tinymail needs the information about all configured accounts - and the mechanism that it uses for that is TnyAccountStoreIface. We don't want to use the tinymail-provided TnyAccountStore, but provide our own implementation instead: ModestTnyAccountStore. This class implements the TnyAccountStoreIface-interace in terms of the aforementioned ModestAccountMgr. One unexpected function that ModestTnyAccountStore needs to implement is tny account_store get_session (to get the Camel-session). This function must be provided as a public function, with that exact name. Finding the right transport One of the interesting topics in designing a mobile e-mail client is to deal with transports (in particular, SMTP). The reason for that is that the majority of SMTP-servers only allow e-mail from the same network. That means that for example smtp.some-isp.com will only accept mail from (MAIL FROM:) user@some-isp.com, and refuse mail from user@some-other-isp.com, unless the recipient (RCPT TO:) is on the same network.