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

List:       kmail-devel
Subject:    Re: [RFC] Kmail to use Knode message classes and proposed schedule for Knode/Kmail merge
From:       Don Sanders <sanders () kde ! org>
Date:       2001-08-10 16:25:35
[Download RAW message or body]

On Friday 10 August 2001 14:53, Marc Mutz wrote:
> 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). 

Regarding making KMMessage a wrapper. Ok, but initially the 
API of KMMessage shouldn't change, only the implementation.

This way the new KMMessage can be tested for correctness. 
Then the KMMessage API should be extended with load 
on-demand of message parts and I think more importantly 
methods for treating the entire message, message body and 
each message part as a stream. Then KMail can be ported 
over to using these streaming methods and finally 
KMMessage::asString and the like can be removed completely.

Treating message parts as streams should allow large 
messages to be handled efficiently memory wise (speed is 
not so important).

BTW I didn't think 'Outlook' supported news. I thought only 
'Outlook Express' (the no cost one) supports that.

Creation of a separate KMessenger application sounds like a 
good idea for several reasons, I hope that the KMail and 
KNode authors get given appropriate credit.

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.

This sounds fine, but I think just 1..4 is a lot of work.

> [now ready for release]
>
> 6. Move Knode/Kmail semantics over to KMime and
> consolidate. 

I see 5 as optional. I think handling of large messages 
should be the primary goal, integration with KNode 
shouldn't be a priority until the KMail code is mature.

I believe in consecutive incremental changes rather than 
radical change.

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

QTextEdit can give us incremental spell checking with 
highlighting and color quoting in the composer.

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

I don't have much to comment on 7...10 I'd rather leave 
discussion on that until later. Broken code can always be 
replaced.

> 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 :-)

Reimplement the current KMMessage API so that the pain of 
the transition is minimized. Then expose and utilise new 
functionality.

> 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,

I think that MIME framework of mimelib is ok. In the sense 
that it presents a hierarchy of parts. But mimelib is 
fundamentally flawed if its architecture can't handle large 
messages.

I agree the mime api of KMMessage (a list of attachments) 
is substandard, but that is simple to fix. Again handling 
large messages is the priority.

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

Future discussion.

Don.
_______________________________________________
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]