[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Crypto plugins
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2001-10-31 23:11:20
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 31 October 2001 13:56, Jan-Oliver Wagner wrote:
<snip>
> > The actual problem here, is the the MIME implementation of KMail is
> > currently in progress of being rewritten since the library we
> > currently use has a few design limitations.
>
> are there any (even coarse) web pages that roughly describe how it
> all is planned to work together? A picture of it would probably
> explain it better than 1000 words and a web-page is good to refer to.
>

Sorry, we don't make graphics of our designs (maybe that's a 
fault...;-).

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 behaviour 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 additonal 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.

Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE74J2X3oWD+L2/6DgRAsR+AJ9DUgB7GEGXJro/juXziR5kF9bNyACgkJHg
F3wJoJqbHv5wTIzJqHQ5tvs=
=4nau
-----END PGP SIGNATURE-----

_______________________________________________
kmail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail

[prev in list] [next in list] [prev in thread] [next in thread]