inter-plugin dependencies and BC

[Roberto Raggi]

Hi!

On Thursday 08 September 2005 12:53, Alexander Dymo wrote:
> Hi!
> This mail summarises what we've discussed with Ian Geiser at aKademy.
> Current policy in KDevelop is to put all public interfaces people may use
> to lib/interfaces (libkdevelop.so) and implement them somewhere in shell.
> This obviously means that we have lots of interfaces in the core but not
> all of them are necessary for platform applications.
this is impossible :-) we will create a *huge* set of interfaces. Things about 
the C++ programming language support. I'd love to be able to write a plugin 
that extends the C++ support. Of course such plugin needs to know a lot about 
the classes *exposed* by the C++ support(e.g. the C++ AST, the way the C++ 
support store the informations in the Code model, the way the C++ support 
creates new classes, methods, ...).. We can generalize many things in 
libkdevelop.so but not everything.

> The solution is to allow individual plugins to define their interfaces and
> link other plugins to those interfaces. Basically, we'd like to introduce
> inter-plugin dependencies (like Eclipse ;)). The only problem is that we'd
I like it.

> be forced then to keep BC not only in the core interfaces, but in plugins
> as well. And this is not good for us.
we need some sort of versioning.

>
> But there's a way to introduce inter-plugin dependencies and at the same
> time do not care about BC. The solutions is simple - we can use
> QMetaObject::invoke and some kind of IDL compiler.
> Please take a look at attachment where a simple model of kdevelop
> architecture is implemented and two plugins (plugin1 and plugin2) are
> created.
I'm not 100% sure it is a good idea to create/use such tool.

> What do you think about exposing interfaces in that way?
> PS: If we do that, we could move more interfaces from the core to plugins
> (like in Eclipse where you have runtime plugin, resources plugin, etc.).
I'm all for it. I think we already discussed something like that one or two 
years ago. In Qt Designer 4 I *solved* the problem with a library called 
"extension framework". The extension framework is an implementation of the 
adaptor pattern (eclipse uses the same patter to extend the resources.. 
IAdatable, IAdapter, IAdapterFactory, IAdapterManager and so on).

With the extension framework is possible to extend an existing object at 
runtime. This is very useful for extening an object without breaking the BC, 
of for introducing a new version of the interface. For instance suppose you 
have two version of an interface

struct MyInterfaceV1
{ ...
  virtual void method1()  = 0;
};
Q_DECLARE_EXTENSION_INTERFACE(MyInterfaceV1, "org.kdevelop.iface.v1")

struct MyInterfaceV2
{ ...
 virtual void method1() = 0;
 virtual void method2() = 0;
};
Q_DECLARE_EXTENSION_INTERFACE(MyInterfaceV2, "org.kdevelop.iface.v2")

now you can ask which extension your instance support. Of course the instance 
can support both extension. 

 if (MyInterfaceV1 *v1 = qt_extension<MyInterfaceV1*>(m, instance))
   {
      // do something
   }
 else if (MyInterfaceV2 *v2 = qt_extension<MyInterfaceV2*>(m, instance))
   {
      // do something else
   }

the qt_extension<> uses strings as typeid. So if you change the declaration
Q_DECLARE_EXTENSION_INTERFACE(MyInterfaceV2, "org.kdevelop.iface.v2")
with
Q_DECLARE_EXTENSION_INTERFACE(MyInterfaceV2, "org.kdevelop.iface.v2-abi2")

the qt_extension<MyInterfaceV2*>(..) will fail and return a 0x0 pointer.. so 
there is no crash and we can show a message saying the plugin doesn't support 
the extension *whatever*.

an instance can implement more then one type of extension.. And the cool thing 
about the extension framework is that different instances comunicate using 
"abstract classes" (handles). So they don't have to link with a library. If 
you're interesting I can write a small example that show how to use the 
extension framework from two different plugins. 

ciao robe