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
|
NOTE: Most of this stuff is still not represented by code...
Here are the very basic ideas on which the KMime design is built:
1. A message is parsed into an object tree (think DOM) where the nodes
are essentially entities (container for 1 header and 1 body), headers,
bodies, and header fields. Each of these nodes can be filled
independently of each other (for composing a message or for successive
loading from an IMAP server).
2. Each headerfield type corresponds to a single class (eg. for
Content-Type, there's KMime::Headers::ContentType), that can parse it's
specific content and can format it in html (for display).
But there is KMime::Headers::Generic for all the unimportant or
unrecognized fields. It just stores the type and the (unstructured)
content.
3. Each body part type likewise corresponds to a single class (eg. for
text/plain, there'd be a KMime::BodyParts::Text::Plain and for
multipart/signed a KMime::BodyParts::Multipart::Signed), which can
decode the content (ie. base64, encrypted) and make it available as a
QMimeSource (so that e.g. pictures shown inlined need not be saved to
tempfiles first).
For (HTML) display, they can either output an inlined version
(text/jpeg -> <img src="cid:...">; text/plain -> <p
class="quoted">...</p>; you get the idea...) or an "attachment" version
(a small table with information about the part).
4. Some body part classes can act as a proxy for other classes: Eg. in
the case of an attached HTML document with images, the corresponding
KMime::BodyParts::Multipart::Related would have an "effective mimetype"
of text/html and would be as good a a real Text::Html (which it holds
inside), as far as it's behavior is concerned. Likewise, a
Multipart::Signed would have the "effective mimetype" of the contained
object. Or think of Message::ExternalBody
5. Multipart::Signed and Multipart::Encrypted would be another kind of
proxy, too: They would look at the protocol parameter of the
Content-Type header field to decide which one of (possibly more than
one) cryptographic backends to use. Those backend plugins would only
need to provide encrypt/sign/verify/decrypt services (each taking or
outputting the bodies of the two nested body parts), plus meta
information (such as the micalg parameter and for the mimetypes of the
nested body parts).
6. There are already three plugin interfaces planned for KMime:
a. for additional headers
b. for additional body parts (mimetypes)
c. for additional crypto backends
They are planned to be simple, so that we can expect a flood of them for
any mime type you can imagine :-) Thus, they will not allow for
runtime-unloading (at least not in their first incarnation). You can
load them at runtime, but to unload them, you'd need to restart KMail.
They basically provide a factory each, which will be registered in
{field,mime,protocol} type -> factory maps. These maps are used by
KMime::Header and KMime::Entity to construct the right headerfields
resp. bodypart object for the field/body at hand.
Eventually, KMail and KNode will also share a reader and composer,
which will be KParts, so that e.g. the reader can be used to read
mails inside konqueror. Also, both KParts can be used in PIM
applications. The long-term goal is to unify KNode and KMail, so that
they are only thin frontends to a common messaging library.
|
