[Kde-pim] Plugin Question re Kontact Headers

[Ingo Klöcker]

On Sunday 06 September 2009, Lindsay Mathieson wrote:
> On Sun, 6 Sep 2009 05:50:11 am Ingo Klöcker wrote:
> > Yes, that way is broken. See above. A possible solution for this
> > would be to make kontactinterfaces public API. But we do not want
> > to do so. Just recently there was a short discussion about Kontact
> > plugins and we decided not to support the development of arbitrary
> > Kontact plugins by making the plugin interfaces public.
> > Unfortunately, I cannot remember in which thread this was
> > discussed.
>
> Unfortunately I didn't have much look searching for the thread - my I
> ask why there will be no public interface for Plugins? will this be a
> permanent state of affairs?

Here are the main reasons:
- A public interface must be stable. We do not want to guarantee stable 
interfaces because we want to be able to change the interfaces whenever 
we feel it's necessary. We have done so regularly.
- We know of exactly one Kontact plugin that was developed outside of 
kdepim: basKet.
- Kontact should be stable regardless of the used plugins. Since we did 
not keep the (private!) plugin interface stable, the basKet plugin, 
when being built with an outdated copy of the plugin interface, caused 
Kontact to crash.
- We don't want random Kontact plugins.


> I imagine the move to akonadi and a full component based
> Kontact/KMail would be one reason, but I'd hope that once that has
> finalised we could revisit it.

We (I) see no point in integrating random component plugins into 
Kontact. Where I see value is in externally developed plugins for the 
summary page.

With the advent of the component based KMail I forsee interesting new 
ways to handle and present mail, news, feeds, etc., to be explored 
because one can fully concentrate on the presentation of the 
information as a whole without having to spend time or thoughts on 
writting a composer, a viewer for a single message, the infrastructure 
for sending, the handling of a pleathora of protocols (IMAP, POP3, 
SMTP, NNTP, ...), etc.

Recently, there was a blog post by someone who had written yet another 
IMAP mail client just because KMail didn't fully fit his needs. For the 
same reason Tom has developed Mailody. What I think is rather stupid is 
that all those people had to write their own IMAP library. But they had 
little choice because back then there was no ready-to-use IMAP library. 
Now the beauty of Akonadi is that those people don't even have to know 
IMAP (unless they want to use very special IMAP features). Hmm, I think 
I digress. :-)


> > The bottom line is that the development of Kontact plugins is
> > restricted to kdepim. So if you want to develop a Kontact plugin
> > then you should do so in kdepim.
>
> I'd really hope this is not a permanent policy because it pretty much
> kills third part development. of plugins. One of the reasons Outlook
> is so successful and useful is the rich set of third party addons for
> it.
>
> I was hoping to develop a mythtv status monitor plugin for Kontact,
> but there no much point if it has to be included in kdepim - that
> level of dependencies is never going to fly.

Can you elaborate on what this plugin is supposed to do and why you 
think it is suitable as plugin for Kontact. Shall this plugin be a 
full-fledged component? Or is it a plugin for the summary page? How is 
a mythtv status monitor related to Personal Information Management?


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090906/4ff205bf/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/