1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
<part>
<title>Design</title>
<partintro>
<para>In this part, we'll discuss the design of various parts of
<application>modest</application>. We'll not go into the details of
various APIs in this chapter. Please consult the documentation generated
from the source code (<systemitem>gtk-doc</systemitem>) for that.
</para>
</partintro>
<chapter>
<title>Configuration</title>
<para>Configuration is the part of <application>modest</application>
that deals with storing all settings. While the design allows for
alternative implementations, currently
only <systemitem>GConf</systemitem> is supported as a backend.
</para>
<para>
All dealing with configuration is done with
the <classname>ModestConf</classname>-class. It is declared
in <filename> modest-conf.h</filename>, and
the <systemitem>GConf</systemitem>-based implementation in
<filename>modest-conf.c</filename>. As said, there could be
different implementations --
nothing <systemitem>GConf</systemitem>-specific is visible in the
<classname>ModestConf</classname>-<abbrev>API</abbrev>.
</para>
</chapter>
<chapter>
<title>Account Management</title>
<para>
Account Management is the part of <application>modest</application>
that deals with the setting related to sending and receiving of
e-mail. We will follow the libcamel-convention of using the
term <emphasis>store</emphasis> for an e-mail storage/retrieval
server, and a <emphasis>transport</emphasis> for a server that
transports mail to its destination.
</para>
<para>
In practice, the following types are available:
<itemizedlist>
<listitem><emphasis>stores</emphasis>: <abbrev>POP</abbrev>
and <abbrev>IMAP</abbrev>; </listitem>
<listitem> <emphasis>transports</emphasis>: <systemitem>sendmail</systemitem>
and <abbrev>SMTP</abbrev>.</listitem>
</itemizedlist>
</para>
<sect1>
<title>Definitions</title>
<itemizedlist>
<listitem>An <emphasis>account</emphasis> is a named entity
consisting of a <emphasis>store</emphasis> and
a <emphasis>transport</emphasis>. Note: For our mobile use-cases,
the <emphasis>transport</emphasis> cannot be a static entity, but
may depend on the network connection. That is however not part of
Account Management, so not discussed here</listitem>
<listitem>A <emphasis>server account</emphasis> is account
describing the connection with a specific server. Server accounts
come in two type:
<itemizedlist>
<listitem>A <emphasis>transport</emphasis> describes the connection information
(servername, username, password etc.) for a transport
server;</listitem>
<listitem>A <emphasis>store</emphasis> describes the connection information for
a store server;</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</sect1>
<sect1>
<title>Code</title>
<para>The functions to deal with account and server accounts are
located in <classname>ModestAccountMgr</classname>, ie. in
<filename>modest-account-mgr.[ch]</filename>. There function to add
specific values for both, to list the available ones, etc. Please
refer to the source code documentation for details.
</para>
</sect1>
<sect1>
<title>Location in configuration database</title>
<para>
<emphasis>Accounts</emphasis> can be found
in <systemitem>/apps/modest/accounts</systemitem>,
while <emphasis>server accounts</emphasis> can be found
in <systemitem>/app/modest/server_accounts</systemitem>.
</para>
<para>
The following image show an
account <systemitem>accountstest</systemitem> with server accounts
<systemitem>mystore</systemitem>
and <systemitem>mytransport</systemitem>.
<imagedata fileref="modest-account-mgr.png"/>
</para>
<para>
For each of the stores, there are number of parameters specified:
<itemizedlist>
<listitem><emphasis>hostname</emphasis> - the place where the server resides;</listitem>
<listitem><emphasis>username</emphasis> - the username;</listitem>
<listitem><emphasis>password</emphasis> - the password;</listitem>
<listitem><emphasis>proto</emphasis> - the protocal for communication with this server - for
now these are the following valid values (literal strings):
<itemizedlist>
<listitem><emphasis>sendmail</emphasis>;</listitem>
<listitem><emphasis>smtp</emphasis>;</listitem>
<listitem><emphasis>pop</emphasis></listitem>
<listitem><emphasis>imap</emphasis>.</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</para>
<para>In <filename>modest-proto.[ch]</filename> there are various
functions to check whether something is a valid protocol, and
whether it is a transport of a store.
</para>
<para>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.
</para>
<para>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.
</para>
</sect1>
<sect1>
<title>Account Management and Tinymail</title>
<para>
Tinymail needs the information about all configured accounts - and the
mechanism that it uses for that
is <interface>TnyAccountStoreIface</interface>. We don't want to use
the tinymail-provided <classname>TnyAccountStore</classname>, but
provide our own implementation
instead: <classname>ModestTnyAccountStore</classname>. This class
implements the <interface>TnyAccountStoreIface</interface>-interace in
terms of the aforementioned <classname>ModestAccountMgr</classname>.
</para>
<para>
One unexpected function
that <classname>ModestTnyAccountStore</classname> needs to implement
is <symbol>tny account_store get_session</symbol> (to get the
Camel-session). This function must be provided as a public function,
with that exact name.
</para>
</sect1>
</chapter>
<chapter>
<title>Finding the right transport</title>
<para>
One of the interesting topics in designing a mobile e-mail client is
to deal with transports (in
particular, <acronym>SMTP</acronym>). The reason for that is that
the majority of <acronym>SMTP</acronym>-servers only allow e-mail
from the same network. That means that for example <systemitem>
smtp.some-isp.com</systemitem> will only accept mail from
(<command>MAIL FROM:</command>) <systemitem>
user@some-isp.com</systemitem>, and refuse mail
from <systemitem>user@some-other-isp.com</systemitem>, unless the
recipient (<command>RCPT TO:</command>) is on the same network.
</para>
</chapter>
</part>
|
