[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
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2001-08-10 18:28:59
[Download RAW message or body]

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

[Please Cc: knode-devel - thanks.]

On Friday 10 August 2001 18:25, Don Sanders wrote:
> On Friday 10 August 2001 14:53, Marc Mutz wrote:
<snip>
> Regarding making KMMessage a wrapper. Ok, but initially the
> API of KMMessage shouldn't change, only the implementation.
>

This is the plan! Else we wouldn't need to bother with KMMessage and 
port the rest of Kmail over to KMime. I don't know yet whether we can 
keep KMMessage 100% compatible. A few adjustments are OK, IMO, but more 
isn't our goal.

> This way the new KMMessage can be tested for correctness.
<snip>

KMime will experience a big regression testing, in the optimization 
stage. That's what's meant with "optimizing for RFC-compliance".

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

IMO speed is also important, but I agree that the priority lies in 
saving memory, yes.

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

Wouldn't you think that these two projects would team up with the 
kdepim guys anyway for that? :-)

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

Yes, and due to that work, integrating this stuff will be _very_ easy. 
Ingo and I will have a bit of influence regarding the PGP stuff Ian 
does, so we can make sure that it will integrate perfectly.

> > [now ready for release]
> >
> > 6. Move Knode/Kmail semantics over to KMime and
> > consolidate.
>
> I see 5 as optional.

I see 5 as essential. The next version of Kmail should really, really 
support rfc2015. We are laughed at for this from the gnupg guys, 
believe me.

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

I do, too (here). The integration with KNode will happen naturally once 
we use the same message handling classes. It's then simply too much 
work to have two readers and two composers. The rest can wait, of 
course.

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

ACK. This is the plan.

> Future discussion.
<snip>

ACK2 ;-)

Marc

- -- 
The intensity and complexity of life, attendant upon advancing 
civilization, have rendered necessary some retreat from the world, and 
man, under the refining influence of culture, has become more sensitive 
to publicity, so that solitude and privacy have become more essential 
to the individual; but modern enterprise and invention have, through 
invasions upon his privacy, subjected him to mental pain and distress, 
far greater than could be inflicted by mere bodily injury.
S.D. Warren/L.D. Brandeis: The Right to Privacy, Harvard Law Review 
vol.IV, no.5 (1890)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7dEIg3oWD+L2/6DgRAqRrAKCO+IeF9m/SO2P3aiUw7NxoiGZG4gCffSez
2pyeagvI2hzke80QSithH7o=
=PMts
-----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]