RFC: problems with splitting up kdebase

David Faure faure at kde.org
Wed Jun 27 10:32:05 BST 2007


On Tuesday 26 June 2007, Thiago Macieira wrote:
> David Faure wrote:
> >On Tuesday 26 June 2007, Thiago Macieira wrote:
> >> It was not my idea to auto-generate adaptors during compilation.
> >
> >Committing the adaptor code in svn was giving us huge discrepancies
> > between the xml and the adaptors, introducing bugs everywhere
> > (non-implemented methods, wrong argument types, typos, etc. etc.). This
> > was certainly not a valid solution.
> 
> I don't understand how. This is the same principle as a header file in a 
> library: binary compatibility. You can only add methods, never remove 
> those that are there. Changing the signature is equivalent to removing 
> the one that is there and adding a new, unrelated one.

You're starting from a situation where everything works already.
But this isn't the case. We're porting from dcop, and many dbus interfaces
were written without testing. Therefore the need for adding, removing,
fixing typos, etc. We're not at "binary compatibility" stage yet, (by far,
for some dbus interfaces).

Did you miss all the commits that fixed dbus adaptors and .xml files after
I made adaptors generated from .xml files?

Plus the fact that any fix to dbusxml2cpp would not benefit the adaptors
if the adaptors were not automatically generated.

Hand-written adaptors are a very bad idea also because of the introspection xml
in the .h - who's gonna maintain this by hand in addition to the adaptor and the
real xml file? One change, three places? Bah.

But this isn't only about the porting. When writing a new dbus interface,
I have seen far too often people fixing the adaptor by hand so that it
compiles but not updating the .xml accordingly. As a result, you get
a mismatch and stuff doesn't work.

> If an adaptor is generated from a .xml file and that .xml got updated 
> (compatibly), then it means that any NEW methods will not be implemented. 
Well the point is that you will have to implement them, since the adaptor
is calling parent->foo() so you need to implement foo() for this to compile.
Which is good - you can't forget to implement it.

> The *caller* must be able to handle that. Not the callee.
> That's the rule for adding methods to interfaces: new methods may fail if 
> you're calling an old interface. Either check the interface version 
> (which means introducting a version number) or handle the failure.

Sure. But you're talking about the caller here, which is unrelated to adaptors.
(I guess this is back to the original topic; my post was more about why adaptors
should be generated in general :)

> >We need compile-time checking, we don't have unit tests for every piece
> > of kde code.
> 
> Ok. What I described above is equivalent to duplicating the .xml files and  
> not updating all of them.
> The difference being that only one of the many .xml files can be 
> installed. We have to choose which one.
You lost me a bit here. Is this with the idea of "xml files in kdelibs"?
So:
kdelibs/interfaces/dbus/org.kde.KWin.xml with the kde-4.0 konq interface,
(and installed into <prefix>/share/dbus-1/interfaces/)
and kdebase/workspace/kwin/org.kde.KWin.xml with the post-4.0 interface (not installed)
including new methods, and the adaptor generated from it, implementing those methods.

This means that code outside of kdebase cannot use a generated dbus interface to
call kwin. This means dynamic calls, so no compile-time checking, and more runtime
bugs popping up. I would much rather see the other KDE modules use the org.kde.KWin.xml
installed by kdebase/workspace (they have a dependency on kdebase-workspace on x11
already, for stuff like plasmaapplet.h) so that they can generate updated interfaces...
This means kdetoys-4.1 depends on kdebase-workspace-4.1 for compilation, but that's fine anyway
(it probably does for plasmaapplet.h changes, too).

OK this example was with kdebase/workspace which ships libs anyway; for code that
doesn't (say, kdepim <-> kdenetwork integration), then the problem is unchanged,
it's either a compile-time dependency, dynamic calls, duplicating xml files
(either in those two modules, or indeed in kdelibs).

So OK, this line of thought makes me conclude: for modules that are a compile-time dependency
already, let's just let them install their dbus xml files. For modules which export dbus
interfaces to other kde modules, they can make a copy of that interface in kdelibs (they
need to remember to update it now and then ;).
And IMHO modules which export dbus interfaces for user scripting, don't need to put a copy
in kdelibs.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kde-core-devel mailing list