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

List:       kmail-devel
Subject:    Re: KMail I (1/2)
From:       Don Sanders <sanders () kde ! org>
Date:       2001-07-24 12:06:08
[Download RAW message or body]

On Tuesday 24 July 2001 09:17, Stefan Taferner wrote:
> On Monday, 23. July 2001 19:18, Kurt Granroth wrote:
> > I'm not going to comment on most of this... but I will 
pipe up here:
> > > We all know that the KMail codebase is in an urgent
> > > need for a redesign. The most imminent problems are:
> > >
> > > 1. doc / view isn't clearly separated. Look at
> > > KMHeaders. 2. We're slow on large and/or many
> > > messages. 3. Limited extensibilty for new features
> > > because of 3a. folders assuming they are in mbox
> > > format. 3b. using mimelib[1]
> > >   3c. (1)
> >
> > It is possible to support arbitrary non-mbox format
> > local folders with the current codebase without TOO
> > much radical redesign.  I have had "native" maildir
> > support for KMail working on my local copy for over a
> > month now. 

Cool. BTW did you manage to incorporate the changes made by 
Sam's patch? They were substantial.

> > Basically, I separated the classes like so:
> >
> > KMFolderNode
> >  +- KMFolder (abstract)
> >     +- KMFolderMbox
> >     +- KMFolderMaildir

Yes, sounds sensible.

> >        +- KMFolderImap

Hmm. That makes sense to me if KMFolderImap is limited to 
being a persistent cache, and the IMAP synchronization 
logic is kept in KMAccountIMAP.

But I wonder what is the difference between KMFolderImap 
and KMFolderMaildir, what special changes were required for 
imap.

> > If you wanted, say, database support, it shouldn't be
> > that much harder than creating a KMFolderDatabase class
> > that inherits KMFolder (and then handle the account
> > stuff but that's mostly just copy/modify/paste).

Yes.

> You will probably need some connect/disconnect mechanism
> and somebody who holds the connection. Similar to IMAP. I
> once called this connection-holding class (KM)FolderGroup
> :-)
>
> The object tree in the KMFolderTree widget would look
> like this: KMFolderGroupManager
> +- KMFolderGroupMbox
>   +- KMFolderMbox
>   +- KMFolderMbox
>
> +- KMFolderGroupImap
>   +- KMFolderImap
>   +- KMFolderImap
>
> With the assumption that the user has mbox folders for
> his local folders and one imap account with two remote
> folders in it.
>
> The KMFolderGroupManager is some simple management object
> that knows about all the groups of folders the user has.
> It would be possible to have a completely imap-only kmail
> this way, for example.

Hmm, yes inheritance makes some sense here.

I don't think the KMFolderGroup* classes are needed though 
since any KMFolder* can have child folders.

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]