4 <para>In this part, we'll discuss the design of various parts of
5 <application>modest</application>. We'll not go into the details of
6 various APIs in this chapter. Please consult the documentation generated
7 from the source code (<systemitem>gtk-doc</systemitem>) for that.
12 <title>Configuration</title>
13 <para>Configuration is the part of <application>modest</application>
14 that deals with storing all settings. While the design allows for
15 alternative implementations, currently
16 only <systemitem>GConf</systemitem> is supported as a backend.
20 All dealing with configuration is done with
21 the <classname>ModestConf</classname>-class. It is declared
22 in <filename> modest-conf.h</filename>, and
23 the <systemitem>GConf</systemitem>-based implementation in
24 <filename>modest-conf.c</filename>. As said, there could be
25 different implementations --
26 nothing <systemitem>GConf</systemitem>-specific is visible in the
27 <classname>ModestConf</classname>-<abbrev>API</abbrev>.
32 <title>Account Management</title>
34 Account Management is the part of <application>modest</application>
35 that deals with the setting related to sending and receiving of
36 e-mail. We will follow the libcamel-convention of using the
37 term <emphasis>store</emphasis> for an e-mail storage/retrieval
38 server, and a <emphasis>transport</emphasis> for a server that
39 transports mail to its destination.
43 In practice, the following types are available:
45 <listitem><emphasis>stores</emphasis>: <abbrev>POP</abbrev>
46 and <abbrev>IMAP</abbrev>; </listitem>
47 <listitem> <emphasis>transports</emphasis>: <systemitem>sendmail</systemitem>
48 and <abbrev>SMTP</abbrev>.</listitem>
53 <title>Definitions</title>
55 <listitem>An <emphasis>account</emphasis> is a named entity
56 consisting of a <emphasis>store</emphasis> and
57 a <emphasis>transport</emphasis>. Note: For our mobile use-cases,
58 the <emphasis>transport</emphasis> cannot be a static entity, but
59 may depend on the network connection. That is however not part of
60 Account Management, so not discussed here</listitem>
61 <listitem>A <emphasis>server account</emphasis> is account
62 describing the connection with a specific server. Server accounts
65 <listitem>A <emphasis>transport</emphasis> describes the connection information
66 (servername, username, password etc.) for a transport
68 <listitem>A <emphasis>store</emphasis> describes the connection information for
69 a store server;</listitem>
77 <para>The functions to deal with account and server accounts are
78 located in <classname>ModestAccountMgr</classname>, ie. in
79 <filename>modest-account-mgr.[ch]</filename>. There function to add
80 specific values for both, to list the available ones, etc. Please
81 refer to the source code documentation for details.
86 <title>Location in configuration database</title>
88 <emphasis>Accounts</emphasis> can be found
89 in <systemitem>/apps/modest/accounts</systemitem>,
90 while <emphasis>server accounts</emphasis> can be found
91 in <systemitem>/app/modest/server_accounts</systemitem>.
95 The following image show an
96 account <systemitem>accountstest</systemitem> with server accounts
97 <systemitem>mystore</systemitem>
98 and <systemitem>mytransport</systemitem>.
99 <imagedata fileref="modest-account-mgr.png"/>
103 For each of the stores, there are number of parameters specified:
105 <listitem><emphasis>hostname</emphasis> - the place where the server resides;</listitem>
106 <listitem><emphasis>username</emphasis> - the username;</listitem>
107 <listitem><emphasis>password</emphasis> - the password;</listitem>
108 <listitem><emphasis>proto</emphasis> - the protocal for communication with this server - for
109 now these are the following valid values (literal strings):
111 <listitem><emphasis>sendmail</emphasis>;</listitem>
112 <listitem><emphasis>smtp</emphasis>;</listitem>
113 <listitem><emphasis>pop</emphasis></listitem>
114 <listitem><emphasis>imap</emphasis>.</listitem>
120 <para>In <filename>modest-proto.[ch]</filename> there are various
121 functions to check whether something is a valid protocol, and
122 whether it is a transport of a store.
125 <para>Note that server accounts and accounts are relatively independent. While
126 accounts refer to two server accounts, these server accounts can be
127 used by other accounts as well.
130 <para>The reason to keep accounts and server accounts separately, is a bit of
131 flexibility. In mobile use-cases, quite often it's desirable to use a
132 network-specific smtp-server. The chosen structure makes it easy to iterate
133 over all smtp-servers and find the right one.
138 <title>Account Management and Tinymail</title>
140 Tinymail needs the information about all configured accounts - and the
141 mechanism that it uses for that
142 is <interface>TnyAccountStoreIface</interface>. We don't want to use
143 the tinymail-provided <classname>TnyAccountStore</classname>, but
144 provide our own implementation
145 instead: <classname>ModestTnyAccountStore</classname>. This class
146 implements the <interface>TnyAccountStoreIface</interface>-interace in
147 terms of the aforementioned <classname>ModestAccountMgr</classname>.
151 One unexpected function
152 that <classname>ModestTnyAccountStore</classname> needs to implement
153 is <symbol>tny account_store get_session</symbol> (to get the
154 Camel-session). This function must be provided as a public function,
155 with that exact name.
161 <title>Finding the right transport</title>
163 One of the interesting topics in designing a mobile e-mail client is
164 to deal with transports (in
165 particular, <acronym>SMTP</acronym>). The reason for that is that
166 the majority of <acronym>SMTP</acronym>-servers only allow e-mail
167 from the same network. That means that for example <systemitem>
168 smtp.some-isp.com</systemitem> will only accept mail from
169 (<command>MAIL FROM:</command>) <systemitem>
170 user@some-isp.com</systemitem>, and refuse mail
171 from <systemitem>user@some-other-isp.com</systemitem>, unless the
172 recipient (<command>RCPT TO:</command>) is on the same network.