RFC: problems with splitting up kdebase

[David Faure]

On Wednesday 27 June 2007, Thiago Macieira wrote:
> David Faure wrote:
> >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).
> 
> Indeed, for this stage in development, I agree that auto-generating is 
> better.

Phew :)

> But are we going to go back to pre-generated files? In special, what about 
> the tarballs?

If the adaptor has been autogenerated during all the development and testing,
why not stick to that in the future too? Any "just before the release" change
is recipe for trouble.
I don't see a problem with the tarballs being as they are now: after all QtDBus
is a requirement anyway, so qdbusxml2cpp can be a requirement just the same.

> >Plus the fact that any fix to dbusxml2cpp would not benefit the adaptors
> >if the adaptors were not automatically generated.
> No major changes are expected soon. This is not an issue.
I was talking about the past, where it has changed quite substantially.
I know it probably won't happen much again, but it was just another strong
reason for moving to autogenerated adaptors.

> >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.
> 
> The XML in the .h is just there to speed up the lookup. If it isn't there, 
> one will be auto-generated. 
Which proves that generated adaptors are better (faster) :-)

> >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.
> 
> Remove the XML then. Like I said, it's just there to avoid building the 
> XML at run-time in the first place. I tinkered with the idea of 
> precompiling the entire metaobject in my own branch. Again: completely 
> optional.
I wasn't talking about the introspection xml here, but about the .xml file,
which is needed for making interfaces. Since people won't know the syntax
for all the dbus type codes, maintaining that xml file is troublesome already.
This is why I really prefer the approach of generating xml from some C++
header, and then generating adaptor+interface from that xml. Interesting,
isn't it, it's exactly how dcop idl worked :-)
This way the "source" of it all is a language we know, C++, instead of some
strange xml.  (If anyone wonders how to do this: cf kdelibs/kio/misc/kwalletd;
there the xml is generated from a hand-written adaptor, but it could just as well
be generated from the real class instead, kwalletd.h).

I really wish that the dbus tutorials out there used that approach instead of
requiring that people learn those strange dbus type codes, or use qdbuscpp2xml
for a one-time conversion. Better let qdbuscpp2xml generate the xml all along
the development of that dbus interface...

> >> 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.
> 
> Indeed, that's the point: if you updated the XML, it means you are about 
> to update the implementation as well.
> 
> In this stage in development, I agree that causing errors is best, to 
> catch porting errors. But once the interface is established and 
> published, there's no need to continuously update the XML file.
Why? Surely you will add more methods later. Nothing is "one time only".

> In special, the XML description can diverge from the implementation.
How?

> >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.
> 
> There's one authoritative source for the XML files. That's the one that is 
> installed. Call it "the original".
> 
> All other files about the same interface are "copies". They don't ever get 
> installed. Whether they are more recent or less is no matter.

Agreed. But note that the "original" can be updated at some point.

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