[Kde-pim] Plugin Question re Kontact Headers

[Allen Winter]

On Tuesday 08 September 2009 3:03:23 am Volker Krause wrote:
> On Monday 07 September 2009 19:22:00 Allen Winter wrote:
> > On Monday 07 September 2009 4:37:36 am you wrote:
> > > On Monday 07 September 2009 09:33:08 Tom Albers wrote:
> > > > At Monday 07 September 2009 01:10, you wrote:
> > > > > Yah. However it appears the main Kontact developers just don't want
> > > > > to pursue that, doesn't fit with their vision of Kontact. Fair
> > > > > enough, that's their privilege and I don't want to waste their and my
> > > > > time pursing it. I appreciate their making it clear at least.
> > > >
> > > > I've not seen a reaction of the Kontact developers / maintainers (as
> > > > far as they exist anyhow).
> > >
> > > That's the real problem here. We don't really have someone working on
> > > Kontact and thus also noone who could make the interface public (which is
> > > more work than just installing the headers). I'm in favor of doing that
> > > as well btw.
> >
> > I was the person who took the old kontact/interfaces and made it into
> > kontactinterfaces precisely for moving into kdepimlibs.  In fact, I had
> > it in kdepimlibs for a day or two.  But then at least 1 former Kontact
> > developer convinced me that this wasn't a good idea because
> >
> > 1) the API hadn't been stabilized or reviewed
> > 2) we wanted to maintain control; we don't see Kontact as a general
> > purpose shell for plugging anything at all.
> >
> > Basically, we figured any future plugins should/could become part of the
> > kdepim module.
> >
> > After all these years, I really think the argument for 1) is getting silly.
> 
> Yep. Still, we should do the usual review for common BC pitfalls (probably 
> done already) and make sure that we have the necessary safety checks in place 
> to prevent Kontact from loading incompatible plugins (IIRC done as part of 
> the enterprise branches, I remember seeing grayed out icons in the sidebar in 
> that case).
> 
> > We can't stop folks from copying kontactinterfaces to their local source
> > tree. So maybe we just give up the idea of control and move
> > kontactinterfaces into kdepimlibs.  Or, we create a white list of plugins
> > we know and take full control. Or.. we do both.
> 
> This is free software, there is no way we can control what people do with it 
> anyway. Obviously the current approach failed in that respect. In fact the 
> number one reason for problems with 3rd party plugins was not the plugin 
> itself, but that it was using incompatible interfaces. So, if you are 
> concerned about the impact of those plugins on the overall quality of Kontact 
> you should rather ensure that people can write plugins (which they will do no 
> matter what) in a safe way by using the official interfaces. Also, I don't 
> think Kontact will suddenly be swamped with hundreds of plugins, I would 
> rather expect a handfull of them. And most of the ideas I've seen so far made 
> perfect sense to me (the new blogging app, choqok, etc.). As long as we have 
> a sensible set of plugins enabled by default (eg. not all of KMail, Mailody, 
> KNotes and KJots), I don't see how even multiple plugins that have a similar 
> task would be a problem.
> 

Ok then.
Unless there are further strenuous objections, I'll plan to move kontactinterfaces
back to kdepimlibs well before the 4.4 soft freeze so we have time to make
at least a basic review.

-Allen
_______________________________________________
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/