Malaga Discussions I
mo85 at cornell.edu
Sun Aug 28 18:09:09 BST 2005
On Sunday 28 August 2005 07:00, Stephan Kulow wrote:
> I wanted to blog about it, but then I figured I should just write a mail
> here, so everyone knows what we discussed.
First, let me thank you for sharing this information.
> So far this is a User and Administrator conference in Malaga, but as the
> KDE e.V. meeting was before that many KDE developers are here too (just
> reviewed the remaining tickets and it will be fun if everyone of those
> arrived... ;). So we came together in the afternoon and discussed some
> issues that we consider interesting enough to discuss.
> The first one was IPC. We once again summarized the benefits of KDE
> switching to DBUS (among the lines of 'well maintained', 'support from
> toolkits and other desktops', 'distribution support already very high')
> and what bothers us with it ('C API', 'unsolved performance problems',
> 'unknown upgrade path').
Here, I have to express disappointment (most of the points have to do with
hype and not anything technical), though I am hardly surprised (see 'hype').
Perhaps I am mistaken, but has D-Bus reached any sort of API, ABI, and wire
compatibility stability? Has the protocol been properly specified? (If the
wire compatibility is stable, and the spec is finally reasonably complete, I
can probably do a client implementation in a weekend).
I am also curious as to what unsolved performance problems the D-Bus authors
managed to invent ;-) , considering that RPC is a very well-understood thing,
and that DCOP manages to work fine performance-wise 99% of the time, despite
some pretty bad limitations in the server implementation that do bite us
Oh, and has anyone volunteered to port the zillions of calls, and to do it in
a way that doesn't totally break everything for a month?
> So it was pretty clear, that we do should switch, but what we discussed
> in a pretty long and heated discussion was: how and on what level should
> we support applications accessing the KDE3 dcop interface. And so far
> we only found one use case that we consider important enough to support
> it: kpresenter/kdetv for KDE3 wants to disable the screensaver running
> within KDE4.
This would be hard to implement without races or bloat. If you have KDE3 apps
starting DCOPServer, then the KDE4 screensaver service has to poll for it, and
hence it may miss the call, though that's probably unlikely enough that we
don't have to bother w/it. The other alternative it to run 2 IPC servers.
Though even the polling scenario means we would still need to ship (and load
with the default desktop) a client implementation. Not particularly bloated,
but if we really head down this road, it might be best to just cut the line
> All other dcop3<->dcop3 conversations have to be supported in
> a way as we do now when KDE applications started under twm. In that area
> KDE4 just has to make sure not to get in the way of KDE3 (e.g. different
> file names for communication sockets).
So basically you want KDE4 and KDE3 completely isolated? Fair enough.
More information about the kde-core-devel