You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
64 lines
3.3 KiB
64 lines
3.3 KiB
15 years ago
|
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.
|