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

List:       kmail-devel
Subject:    Re: (Response Part 2) Re: KMail II for KDE 3 - on delivery and storage methods.
From:       Don Sanders <sanders () trolltech ! com>
Date:       2001-07-25 19:32:16
[Download RAW message or body]

On Wednesday 25 July 2001 21:23, Don Sanders wrote:
> On Wednesday 25 July 2001 18:31, Marc Mutz wrote:
> > On Wednesday 25 July 2001 17:20, Don Sanders wrote:
> > > On Wednesday 25 July 2001 15:13, Marc Mutz wrote:
> >
> > <snip>
> >
> > > > The new message class will provide both. I
> > > > will see to it.
> > >
> > > This isn't a message class issue.
> >
> > I agree. Only the mbox folder needs the message to
> > store this information, because....
> >
> > > It's a KMFolder issue, both for mbox (where the mbox
> > > file has to be updated to reflect the new status of
> > > the message)
> >
> > ... one of the /*status*/i headers is being updated,
> > right?
>
> Yes.
>
> Now combine this with an mmap'ed mbox file and a
>
> > message class that allows certain headers to write to
> > the original buffer - e voila. ;-)
>
> Sounds good but I fear there is a problem with mmaping
> the mbox file - it (is yet another thing that) won't work
> with nfs.

To solve the handling of large messages problem I think 
that KMMessage and KMMsgPart methods that like 
KMMessage::asString, KMMessage::bodyDecoded that return 
QCStrings and QByteArrays must be phased out and replaced 
by methods that return a stream (QIODevice based class) 
instead) and that quite some KMail code must be modified to 
work on streams instead of strings.

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]