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

[Matt Rogers]

On Friday 19 January 2007 10:15 am, Alexander Dymo wrote:
> > > 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
>

By old, I assume you mean post 4.0 plugins. I don't think we could load KDev 
3.x plugins in KDev 4 even if we wanted to.

> 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.
>

Quanta is not the only user of the shell. Mathieu Chouinard is also working on 
something using Koncrete, so we need to keep BC here. If it will be a library 
with a set of exported interfaces, we need to keep BC. A layman's definition 
of BC means that we can add and deprecated, but we can't change or remove 
existing functions.

>   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.
>

I think we need to maintain BC. Maintaining BC is not that hard. We've done it 
pretty well for the KDE 3 series for quite awhile. Yes, there have been some 
mess ups but for the most part, it's been quite successful.

> > > 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.
>

-- 
Matt