Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features.

BUG:215923


git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdepim@1054174 283d02a7-25f6-0310-bc7c-ecb5cbfe19da

1 files changed, 63 insertions, 0 deletions

diff --git a/libkmime/DESIGN.kmime b/libkmime/DESIGN.kmime
new file mode 100644
index 000000000..c949ec78a
--- /dev/null
+++ b/libkmime/DESIGN.kmime
@@ -0,0 +1,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.