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

List:       kmail-devel
Subject:    KDE mail delivery and retrieval kioslaves
From:       Marko Gronroos <magi () utu ! fi>
Date:       2001-05-14 21:57:31
[Download RAW message or body]

(Note: Please Cc replies to magi@iki.fi, as I'm not on the kmail list yet.)

I've been rewriting the mail conduit of KPilot. The old (currently used)
version has many mail delivery and retrieval methods implemented, but it has
severe limitations and quite a lot of redundant code.
  I wasn't aware of the existing mail kioslaves when I started a little while
ago (and I guess nobody else was), but I managed to implement a rather simple
and general framework for mail delivery and retrieval agents, which doesn't
use kioslaves yet. (The framework is not yet in the CVS). I've implemented the
Pilot-mail transfer, and SMTP delivery and Unix mailbox retrieval agents.
  But, now that I know that some of the required kioslaves exist, I wouldn't
like to reinvent the wheel. Kioslaves would also be much more generic
approach.

However, the current mail slave implementations don't appear satisfactory to
me, so I would like to ask what plans you have about them?

I took a quick look at the existing slaves, especially SMTP.
  The SMTP delivery implementation is not good for our purposes. Most
importantly, it takes the mail header stuff as KURL parameters, constructs the
header itself, and then adds body. This is bad, because we must be able to use
our own headers. The SMTL slave also doesn't use any MIME encoding stuff,
which would be very critical. Etcetc.
  There doesn't seem to exist a Unix mailbox KIO slave. It would probably be
the most important MRA, and would also be very useful also for handling
user-defined mail folders.
  Thus, the current mail kioslaves simply won't do, and they seem to suffer
from about the same problems as KPilot agents did before I started rewriting
them.
  IMAP4 seems to have much of the required stuff, but it would have to be
generalized (and not duplicated) for the other agents as well.

If nobody else is working on more generalized interfaces and support
libraries, I could look into it, as I've been already doing it for KPilot.

The mail agent interfaces of my current framework for KPilot mail conduit are
pretty simple:

    class MailRetrieval { ...
        virtual int      open         (const KConfig&);
        virtual Message* nextMessage  ();
        virtual void     delivered    (Message&);  // i.e. remove
        virtual void     close        ();
    };

    class MailDelivery { ...
        virtual int      open         (const KConfig&);
        virtual int      deliver      (const Message&);
        virtual void     close        ();
    };

Most of the MIME encoding stuff is hidden behind the Message class, so mail
agent implementations don't have to do it themselves.
  My framework works now for KPilot's purposes, but it would have to be
refined much further for a more generalized implementation.

-- Marko Grönroos, magi<at>iki.fi (http://www.iki.fi/magi/)
-- Paradoxes are the source of wisdom and the end of truth

_______________________________________________
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]