interfaces / implementations separation (was Let's discuss KDevelop4 interfaces and shell)

[Alexander Dymo]

> > 3) abstract, minimal, clean and independent interfaces would:
> > - allow us to not care about BC in the shell
> > 	Our "shell" (read implementation of a plugin loader, project loader,
> > 	main window stuff) should not be kept BC. Shell is evolving target
> > 	and keeping BC there would make it harder to improve KDevelop.
>
> I'm not sure I have fully understood all aspects of keeping BC, but I
> think the goal is that the shell is part of the platform, so for
> instance Quanta doesn't need to provide its own shell. In that case, why
> don't we need to keep BC in the shell? If Quanta uses the shell it
> surely isn't good if its ABI changes.

There're two goals:
1) to make sure all old plugins load in new versions of KDevelop
  and Quanta (let's call this plugin architecture BC).
  We need this to support third-party plugins and plugins from
  (not yet created) kdevelop-extragear

2) to make sure Quanta application can use the same shell.
  Here we don't really need a BC. Quanta and KDevelop usually
  have the same release cycle so they will most likely end up
  installing the same version of shell. So no BC-keeping is necessary at all.

  Alternatively we can keep BC between minor releases (like
  allow updating Koncrete (platform) and KDevelop to 4.0.6 while still 
  working with Quanta 4.0.0.

  Actually I'd like to see the second approach taken.


> > What I want our interfaces to be:
> > 1) The entry point to understanding KDevelop architecture
> > 2) The clear set of things all platform plugins can
> > use/call/access/whatever.
>
> One problem we might face here, especially with BC in mind, is that we
> need to define _now_ what we allow for plugins to use and I'm not so
> sure we don't want to change that in the future (before KDevelop5). But
> maybe you "older" devs have a clearer view about that than I have. I
> certainly don't know for sure if the current API for our importers is
> enough or if we need more stuff there...
Well, we have quite a lot experience with KDevelop3 and we certainly can
solve this problem.