[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC: DBUS & KDE 4
From:       "Maksim Orlovich" <mo85 () cornell ! edu>
Date:       2004-09-29 17:12:40
Message-ID: 3398.128.84.98.57.1096477960.squirrel () 128 ! 84 ! 98 ! 57
[Download RAW message or body]

> [Don't reply if you haven't read the whole message]
> [If you do not fully understand how DCOP or DBUS works, make sure to gain
> a
> full understanding by asking meaningful questions BEFORE voicing an
> uninformed opinion that makes you look like a fool [2]. It will also keep
> you
> off the kde-core-devel auto-reject list.]

(I believe writing an implentation of most of ICE, DCOP, and a somewhat
more sophisticated class project called SDO, which has far more precise
semantic guarantees than either DCOP or DBUS, along with dozens of
protocols, and heaving read the D-BUS spec, and being one of the few
people who have actually read the ICE spec, makes me somewhat qualified.
You would have to threaten me w/something more substantial than an
application of moderator priviliges which unfortunately reeks of conflict
of interest to make me read all 30,000+ lines of code in the DBUS library,
however)

>
> Hi,
>
> I would like to discuss how KDE 4 is going to support DBUS. There are a
> few

I think a question to ask before is WHETHER KDE will support DBUS. Asking
HOW presupposed that it will. Which, to the best of my knowledge, has not
been ever agreed upon in a public mailing list discussion.

> different possibilities here, several requirements of varying hardness and
> all this is constrained by what is actually technically possible.
>
> Technically DBUS provides roughly the same capabilities as DCOP. This is
> not

It also lacks quite a few capabilities, such as DCOP's deadlock avoidance
strategies; and suffers from an inferior base protocol that does not
provide features such as version auto-negotiation and fully modular
authenicaton system. I can not tell whether asynchronous replies are valid
from the spec. The sequence numbers certainly make it possible, but the
spec doens't really provide any sort of a clear semantic, on blocking,
ordering, etc. These sorts of things can cause awfully subtle recursion
bugs.

<snip>

> accepted single IPC mechanism for information like this in the form of
> DBUS
> would make it easier to export information from the kernel or root-based
> system services to non-root user space which in turn will make it easier
> for
> KDE to write KDE applications that integrate better into the operating
> system.

Of course, there is no particular technical reason to use D-BUS as such a
protocol.

>
> _THE_ Unix/Linux IPC standard we can use it as part of other standards. It
> will also make it easier to let non-KDE applications integrate into the
> KDE
> desktop.

Integrating w/DCOP is not hard either, as evidenced by having 3 separate
implementations of the protocol that can interoperate w/each other, 2 of
them not using Qt, and one not using libICE.


> For the above reasons DBUS is very interesting technology, and there is
> significant demand for DBUS support from KDE application developers. As
> such

I am sure those developers that would like to see this can say for
themselves.

> there is no doubt that DBUS will be used in the near future by KDE
> applications.

There is a bit of circular logic here: this discussion makes it likely,
and you're using that to motivate D-BUS.

> The question for KDE then becomes how we are going to support DBUS in
> relation
> to DCOP. The main concern here is backwards compatibility.

Indeed.

>
> There are several approaches, some of them really good, some of them
> really
> bad, some of them perfect but not feasible.

0) Do not provide KDE-wide support for DBUS. Individual applications that
need support may use an external library.

> 1) Provide DBUS support in addition to current DCOP support, keep the two
> worlds separate.

No technical difficulties in that.


> 2) Provide DBUS support, deprecate DCOP, convert at runtime all DCOP IPC
> to
> DBUS to provide 100% backwards compatibility.

Tricky to get right, especially with multi client interactions (kded!).
Also, custom marshalling would be tricky: you would have to marshal
recursive types as opaque objects, and you run risk of breaking down on
places which do not use DCOPRef, although, they probably should.

>
> DISCUSSION
> =====1) We also get this if we don't do anything. Applications will start
> to use
> the Qt-DBUS bindings anyway.

Well, there is always the possibility that they wouldn't. And I think it
would be quite likely if there was not the presumption that KDE would
migrate to D-BUS.

> It's a bad situation because developers and
> users will start to get confused about which form of IPC to use.

Can't be much worse than our socket classes :-)


> 2) This sounds like the perfect solution, but is it feasible? It seems to
> me
> that conversion of the call arguments may be impossible in cases where the
> argument types are application defined. Due to the way DCOP works, it is
> only
> possible by the receiving and sending applications in such case to
> separate
> the different arguments. As such, such calls will always look different
> from
> a native DBUS call with the same arguments. Is that a problem? In which
> situations would that cause compatibility issues? Can those be solved in
> another way?

You could try parsing the method signature and pray that it's accurate
(method(QString) does not -HAVE- to use a QString. That's what we get for
not having a written spec!). Or deprecate non-DCOPRef call interface. Of
course, there is the fun type equivalence issue in that passing 2 integers
in DCOP marshals the same as passing a structure w/2 ints (i.e. a QPoint),
so one could theoretically have method(QPoint) and method(int, int)
actually dispatch to the same C++ method. (You did mean -100%-, didn't
you?).

[And custom types can be packaged as an opaque object]

> 3) When I talked about really bad approaches I ment this one. We MUST
> provide
> as much backwards compatibility as possible if we want people to consider
> KDE
> as a serious and stable platform. Every script with "dcop kdesktop
> KScreensaverIface lock" out there that we break means making the KDE
> platform
> less attractive for both end-users and ISVs alike. It will result in a
> bigger
> number on every Microsoft sponsored study out there under "TCO". And the
> really bad thing is that they would actually have a point with that.


Agreed, and thanks for caring about backwards compat. One -major-
complication, though: consider KDE3 applications running under a KDE4.
Remember, the big excuse that's used all the time to break BC when going
KDE N => KDE N + 1 is  that "people can just install old kdelibs". Well,
KDE3 apps are gonna need the dcopserver. And they're gonna need most of
KDE services available through DCOP, in particular kded (with the
cookiejar, kwallet), knotify, klauncher, etc. And not having a dcopserver
running inside KDE4 would effectively partition them off, and cause tons
of problems. What exactly is gonna happen to my wallet file if both the
KDE3 kded, talked to through DCOP,a nd KDE4 kded, talked to through D-BUS,
which are -separate processes- would try to alter it?  If we want to have
KDE3 apps running in KDE4, we -must- support DCOP.


> 4) This is the 95% [1] solution. I think it's easy to pull off and 95% of
> all
> code would never notice the difference. The 5% will mostly be KDE 3
> applications that run in a KDE 4 environment. But as I explained above,
> that
> 5% is still too much. Is there something that we can do to solve the issue
> for this 5%?

As I discussed above, it's more than 5%. In particular, look at Qt4. How
long will it realistically take people to port to THAT? (and I imagine
some people may have hefty plans for kdelibs, too). And providing no
migration path is a pretty big slap in the face to application developers.
If you were an ISV, would you want to use a systemt that breaks
compatibility every 3 years or so w/no clear way for people to run your
app when that happens?

-Maks


[prev in list] [next in list] [prev in thread] [next in thread]