Desktop services (was Re: A little review of kdecore & kdeui)

[Kevin Krammer]

On Sunday 09 April 2006 19:45, Thiago Macieira wrote:

> This would be yet another reason why DAPI should use D-Bus, since it DAPI
> and our *native* calls would be the *same*. I fail to see how
> yet-another-IPC-mechanism, implemented in DAPI, is advantageous. D-Bus
> was *created* to solve that problem and yet, when the time comes to use
> it, DAPI chose to implement its own protocol.

First, Lubos has said numerous times that it is just an option and that he is 
not opposing other IPC mechanisms.

Second, the initial decision seems to be grounded in the warning on the D-Bus 
side that D-Bus is not considered stable yet.
Maybe the wording should be changed to reflect that this means more the client 
library than the protocol/marshalling itself.

Third, at this stage of the development an internal IPC has the advantage to 
not burden either build process or test environment with a correct and recent 
enough external IPC setup.
If it is unnecessarily complex to just test it, the amount of feedback to be 
hoped for might be a lot less.

Forth, generating the D-Bus service structure and the client proxies from the 
abstract API description file is likely more difficult and would reduce the 
number of features Lubos could implement during this important feedback 
period.

Last but not least I'd like to say that I am in favor of using D-Bus not only 
as the IPC but also as the API specification, i.e. specifying the API in the 
form of D-Bus introspection files.

However, like in all other aspects of free software development, those who 
provide the code decide. So unless some other developer besides Lubos and 
myself show up for work on DAPI, I'd rather have a working solution using its 
own IPC than having a vaporware solution based on something else.

Cheers,
Kevin

-- 
Kevin Krammer <kevin.krammer at gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtcentre.org
-------------- 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/20060410/b0d49748/attachment.sig>