Surely the dcop inteface for KMail is perfectly suited for use as an 
interface for plugins.

The dcop interface can continue to be extended to meet the needs of 
plugins and external client apps. If a plugin author or whoever wants 
the dcop interface to be extended I think it's up to them to work out 
how it needs to be extended, and preferable provide a patch 
implementing that interface.

There are a lot of feature requests for KMail. Features requested to 
satisfy very specific needs. It would be easy to implement many of 
these, but stupid to bloat the KMail GUI by adding menu items etc for 
these features.

What I do see there being a need for is a way of having external KMail 
plugins integrate with the KMail GUI. Maybe initially something as 
simple as a gimp like plugins menu would be enough.

Don.

On Tuesday 04 June 2002 16:17, Carsten Pfeiffer wrote:
...
> You need two things in the interfaces:
> 1) events that plugins react on (i.e. "composerOpened", giving
> access to the composer interface, or "messageOpened", giving access
> to the opened message. 2) some sort of library to do something with
> the data, i.e. the mails. Just offering a message as QString is
> nice for the beginning, but some methods for accessing attachments
> or manipulating headers would be nice. Provide a small interface
> around KMime for example, with the most common things that are
> guaranteed to be available after any rewrite.
>
> Cheers
> Carsten Pfeiffer