RFC: DBUS & KDE 4

[Thiago Macieira]

Waldo Bastian wrote:
>2) Provide DBUS support, deprecate DCOP, convert at runtime all DCOP IPC
> to DBUS to provide 100% backwards compatibility.
>4) Replace DCOP with DBUS, adjust dcopidl to generate DBUS code instead of
>DCOP.

>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?
>
>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%?

I agree with you that the combined solution of 2 and 4 seem to be the best 
solution.

If I understand how that would work, we'd:

- convert dcopidl to dbusidl and have it generate D-BUS code. All KDE 4 
applications would therefore talk D-BUS natively.

- write a DCOP-to-DBUS bridge (dcopserver being a D-BUS client, maybe?) 
which would relay messages from DCOP to the D-BUS environment.

- make it so that our current DCOP interfaces when converted to D-BUS also 
register a DCOP object name. Following Zack's suggestion, the registering 
of "org.kde.kdesktop.KScreensaverIface" in D-BUS would also cause the DCOP 
alias "kdesktop KScreensaverIface" to be generated.[1,2]

[1] Maybe we could even have a DCOP namespace inside D-BUS, such as 
org.kde.dcop.kdesktop.KScreensaverIface, in order to allow easier mapping 
between the interface names.

[2] As for the argument marshalling problem you raised, we'd be restricted 
only to those application-defined arguments. We have already changed most 
of our interface to not use such types, preferring instead basic, 
predefined ones (QString, QStringList, etc.)

I believe that with [1] we'd also allow DBUS-to-DCOP relaying, since the 
whole of DCOP would be contained within D-BUS, provided [2] is respected.

In the world of invented statistics, I think we could raise your 95% to 
something around 99%. We'd be left with only those functions that take 
non-standard parameters. Those functions already can't be called from kdcop 
or from the dcop command-line program, since they don't know how to 
marshall objects like FocusPolicy, BackgroundOrigin or BackgroundMode (to 
name a few that already are in our mainWindow DCOP object).

$ dcop kopete mainWindow setFocusPolicy 1
cannot handle datatype 'FocusPolicy'

As for the argument marshalling format of DCOP itself, I find it to be 
flawed in that it doesn't specify the size of the argument that follows. It 
depends exclusively on the other side knowing exactly what the argument 
types are. Therefore, it is not extensible. Therefore, it has been long 
coming that application-defined argument types would someday break.

Having said that, I don't believe doing that breaking now would have such a 
great impact.
-- 
  Thiago Macieira  -  Registered Linux user #65028
   thiago (AT) macieira (DOT) info
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- 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/64b7f145/attachment.sig>