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

List:       kmail-devel
Subject:    Re: support for non mbox style mailboxes?
From:       Jason Stephenson <jjas () engr ! uky ! edu>
Date:       2001-01-31 21:08:36
[Download RAW message or body]

On Wednesday 31 January 2001 15:41, Michael Häckel wrote:

> Currently we do only support mbox format, therefore there is no need for
> such a class. I don't consider that a week design to not implement
> completely unnessary classes. I'm currently also working on IMAP folder and
> even that is possible with the current KMFolder class.
> If we ever have support for another folder format then I don't see, what is
> difficult to add a class that can decide between KMMboxFolder and
> KMMailDirFolder, similar as we currently have that for KMAccount, which
> supports local and pop3 accounts.

I'm fully aware that KMail only supports mbox files now. There has been talk 
of supporting storing mails in a database, now maildir, and who knows what 
else. If you want to support the monster code for all of these in one place 
in KMail, and have one class to switch among them, then that's fine.

I'm suggesting that if KMail is going to support any arbitrary number of mail 
box formats, then it should be done in an intelligent way. We should use 
features of C++ and our libraries that make these things easier. Wouldn't it 
be easier to have a single interface in KMail to the mail box file, and then 
some other class that implements that interface actually worries about how 
the messages are stored? Don't you think it's cleaner, better design to split 
the implementation from the interface as much as possible?

> I think DCOP and IOSlaves are useful for the things they have been written
> for, but handling local files can be done in a more effective way.

DCOP and IOSlaves were just ideas for ways to make it more flexible at run 
time. Instead of compiling all these different mail box handling classes into 
KMail, one could have another app or an IOSlave to handle that particular 
format, and then it could be loaded at run time with little fuss. This cuts 
down on the size of KMail's binary in addition to providing a more flexible 
and extensible interface.

-- 
Jason Stephenson -- UNIX Administrator
University of Kentucky College of Engineering Computing Services
280 Anderson Hall -- 257-5497
jjas@engr.uky.edu
_______________________________________________
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]