RFC: DBUS & KDE 4

[Thiago Macieira]

Waldo Bastian wrote:
>Let me combine a few of the suggestions in a somewhat complete solution:
>
>For compatibility we could generate demarshalling for both the DCOP and
> DBUS calling formats (and mark new interface so that we can only generate
> DBUS interfaces for those). Then we can have the same interfaces
> available in the DCOP and DBUS universe.

This solution would allow any calls coming from DCOP and from DBUS to work, 
even those using custom datatypes.

I am assuming that our non-standard types used all over (QPoint, 
QStringList, etc.) would be mapped to a DBUS CUSTOM type and still be 
allowed.

>To reduce the overhead of the generated code we could even identify cases
> (at compile time) where (the incoming) calls to the
>org.kde.dcop.kdesktop.KScreensaverIface.lock interface can be
> automatically converted to calls to its
> org.kde.kdesktop.KScreensaverIface.lock counterpart. (Must be careful
> with return types though)

Sorry, I didn't understand this one.

What do you mean?

>KDE 4 applications would then be reachable with "DCOP over DBUS" and
> "DBUS" and exisiting code that makes (hand coded) DCOP calls in KDE would
> use "DCOP over DBUS" while dcopidl in KDE4 would generate "DBUS" calls.
> For KDE 3 compatibility we could extend the dcopserver to change DCOP
> calls to DBUS clients into "DCOP over DBUS" calls. The dcopserver would
> then be an optional server in order to obtain KDE3 compatibility.

What is not being addressed here is the DBUS-to-DCOP calls.

For KDE4 apps, calling a "DCOP over DBUS" method would trigger DCOP 
marshalling and route the call via DBUS to the dcopserver, which would then 
relay to the destination. This will require hardcoding of the DCOP aliases 
(org.kde.dcop) and making a special DBUS call.

Non-KDE4 apps will not be able to call any of the interfaces present under 
org.kde.dcop.* unless they themselves use our (tentatively so-called) 
"libkdbus" or "libdcop+dbus".

I would much rather keep the DBUS section clean and let the dcopserver do 
the transmarshalling. Simple types and strings are easy; common custom 
types like QStringList, QPoint, QCursor, QPixmap, QPalette, QSize would be 
encoded to their DBUS equivalents -- which have to exist anyways for DCOP 
to be replaced with DBUS. 

The only problem would be custom datatypes (like enums), which should be 
avoided at all costs as of now. In those cases, when transmarshalling 
fails, dcopserver would transmit the whole QDataStream over D-BUS. At 
compile-time, we would also detect those border cases and write DCOP 
demarshalling code on the app.
-- 
  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/d516980b/attachment.sig>