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 to 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.