RFC: DBUS & KDE 4

[Waldo Bastian]

On Wednesday 29 September 2004 19:12, Maksim Orlovich wrote:
> > 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.

Those are very valid points that need to be addressed indeed.

> > 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.

Ian identified some drawbacks of DCOP and they are all either fixable or 
non-technical. E.g. a drawback of DCOP is that it has this awkward 
marshalling format for custom types, in particular that you don't know its 
size in the stream. Ironically that is mostly a problem when switching to 
something else.

I have heard people talking about lack of TCP support in DCOP, but that 
limitation is a result of policy, not a technical issue in and of itself.

> > _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.

Yes, it's mostly a matter of mindshare that makes the difference.

> 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?).

100% is desirable, but I don't think it will be achievable unless you just 
encapsulate the whole DCOP payload in DBUS and at its destination feed it 
back into the original DCOP demarshalling function. (I called that DCOP over 
DBUS in another message)

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

Well, once we encounter a custom type we don't know where it will end, and 
where the next argument starts, so we can basically only package the totality 
of arguments as an opaque object.

> 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.

I fully agree.

Cheers,
Waldo
-- 
bastian at kde.org  |  Wanted: Talented KDE developer  |  bastian at suse.com
  http://www.suse.de/de/company/suse/jobs/suse_pbu/developer_kde.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040929/925a6577/attachment.sig>