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

List:       kmail-devel
Subject:    Re: KMail IMAP (was: KArchie)
From:       Don Sanders <don () sanders ! org>
Date:       2000-07-31 22:34:35
[Download RAW message or body]

On Mon, 31 Jul 2000, John Corey wrote:
> joerg habenicht wrote:
> > On Mon, 31 Jul 2000, Daniel Naber wrote:
> > > On Mon, 31 Jul 2000, joerg habenicht wrote:
> > > > because I'm working on my thesis right now and have other projects
> > > > like imap-kmail and kuml going on.
> > >
> > > How is that IMAP stuff coming along? The other KMail developers are
> > > very interested in this.
> >
> > well, I had a look into the RFC and shallow look into the imap io-slave.
> > If I'm not mistaken, we could try to hack a very basic support into
> > kmail. I.e. get a list of available mails of the imap server, get the
> > mails and delete mails. It won't be very performant, but a least it could
> > work, and that's what everybody initially wants to have.
> >
> > In my last mailings with Don, he suggested to look into the io-slave
> > first, and then try to code the kmail application.
> >
> > I think, the io-slave may be rather useful right now, so it would be
> > better to do a CVS fork and make an imap beta client. This way the HEAD
> > revision of kmail can mature for KDE2 and the forked imap kmail client
> > would be available shortly afterwards.
>
> I did much of the work on the ioslave before work took over my life. :)
> I know the whole IO Slave architecture has changed quite a bit since
> then.  So the first thing to do is get it converted over.  I've been out
> of KDE devel for about as long, so there's quite a bit of catchup to
> do.  From what I recall, I had the code up to where it would get a list
> of folders, maybe messages too.

The main thing is getting a minimal but working IMAP ioslave implemented. We 
need to be able to login into the server, list message by unique id (uid), 
and get the full text of  a message given its uid, mark a message for 
deletion given it's uid, and close the connection to the server. That's all.

If somebody can get this done they will have made a very significant 
contribution.

After this probably myself or maybe Stefan can modify the KMail code to add 
support for a new type of folder that supports the imap model of messaging 
(which means we connect to the server if possible to find out the state of 
messages on the server, but if we can't connect then we at least allow people 
to read messages that have been downloaded and cached locally). We will also 
initially restrict what can be done with messages in these folders.

After this we will need to add support in the ioslave somehow for getting the 
status of messages, (IIRC status of messages is kept on the server for IMAP). 
Perhaps we can just get the status of all messages on the server.

We will also need support for folders in the ioslave, detecting them, 
creating/deleting them, and moving messages from one to another. We need this 
for handling multiple folders and for filters too.

I don't know how we are going to support moving messages between normal KMail 
folders and IMAP folders, I think that's going to be ugly at best.

(After that I guess you can implement support for the IDLE command so people 
can stay permanently connected to the server and just issue idle commands 
every so often to see if/what changes have been made, which is useful is 
multiple people are concurrently accessing the same folder. We should also 
add support for partially downloading messages, eg just the headers, or 
everything but attachments)

Actually I have never used an IMAP server, this is just how I guess it works 
from scanning a few RFCs and stuff.


I don't have a problem with forking KMail to add IMAP support (perhaps have a 
look in kdenonbeta/kmail2 the code you need may already be there). However I 
think that people should worry about changing the KMail code after a minimal 
but working IMAP slave is implemented.

BFN,
Don.

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