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

List:       kmail-devel
Subject:    [RFC] Kmail to use Knode message classes and proposed schedule for
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>,
Date:       2001-08-10 10:54:16
[Download RAW message or body]

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

Hi!

The Knode developers and Marc Mutz (from Kmail) have come to an
agreement on how to merge the message handling of the two projects.
This will be the first step on the road at whose end Kmail and Knode
are only frontends to a common library and the creation of a
"KMessenger" superset of both to rival Outlook will be possible. We
think that there is a consensus on both sides that this is the way to
go.

We now want to lay out the schedule for this first part (with time
frames intentionally left out of the picture):

1. Outsource KNode classes into libkdenetwork (splitting up KNArticle
into a Knode-specific and a generic part).
2. Rename classes under a KMime:: namespace and port to Qt3.
3. Optimize the classes for both memory usage and RFC compliance.
4. Rewrite KMMessage / KNArticle as wrappers around KMime::Message
(defining a common load/store interface for on-demand loading of
message parts - some KMime::LoadHelper or such).
5. Create a transparent encryption/decryption
(multipart/{encrypted,signed}) interface for bodyparts based on Ian's
work on KGpgMe (codename:-) and George's S/MIME classes.

[now ready for release]

6. Move Knode/Kmail semantics over to KMime and consolidate.
7. Merge reader classes (actually, rewrite them to become a KPart and
maybe use QTextBrowser for mails that don't contain HTML themselves
(should be much faster)).
8. Merge Composers and make them use QTextEdit, so that we can create
text/html (ugh. :-) and text/enriched mails.

[in the future:]
9. Merge the message list classes.
10. Merge the rest (esp. folder handling).

We are aware of the fact that the last five points are rather blurry, 
but we focused on

a. message handling
b. parts that heavily depend on the internal representation of messages 
and thus will profit the most from being merged.
c. parts that we think can be merged without too much pain for the 
Kmail side (ie. folder handling comes last :-)

Though this proposal seems like "Knode takes over Kmail" (or---as 
Christian Thurner has put it: "We are KNode of Borg. You will be 
assimilated. Resistance is futile" :-), this is not so. We use the MIME 
framework of Knode as a basis, because it's technically sound and 
Kmail's isn't, but the outcome of the merge will look quite different 
from current Knode. What with the reader and composer; they will need 
quite a bit of work for the port to QTextEdit and it's not decided in 
any way from which side (Kmail/Knode) we start there.

Comments welcome.

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

iD8DBQE7c9lT3oWD+L2/6DgRAm/GAKD8eHGeD5umLK7+AbzlCHT7PJIqewCeM5Vn
ZECr4KZxUkPtnvxARh50kpY=
=b8kJ
-----END PGP SIGNATURE-----
_______________________________________________
Kmail Developers mailing list
Kmail@master.kde.org
http://master.kde.org/mailman/listinfo/kmail

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