Making dbus optional in Calligra

[Sebastian Sauer]

On 02/08/2012 01:30 PM, Pau Garcia i Quiles wrote:
>
>
> On Wed, Feb 8, 2012 at 1:20 PM, Jaroslaw Staniek <staniek at kde.org 
> <mailto:staniek at kde.org>> wrote:
>
>     On 8 February 2012 11:50, Pau Garcia i Quiles
>     <pgquiles at elpauer.org <mailto:pgquiles at elpauer.org>> wrote:
>     >
>     >
>     > On Tue, Feb 7, 2012 at 3:09 PM, Boudewijn Rempt
>     <boud at valdyas.org <mailto:boud at valdyas.org>> wrote:
>     >>
>     >> And yes, well, of course there are platform-local ways of ipc,
>     on windows
>     >> and android that we might want to use instead of dbus, if there
>     is demand
>     >> for it.
>     >>
>     >
>     > I talked about this with Holger Schöder at FOSDEM.
>
>     What's you opinion - where is QtMobility in this which has the
>     same purpose?
>     If possible - we sure do not want to have this as KDE-only thing.
>
>
> Are you talking about the Publish/subscribe API? He did not mention 
> anything.
>
> The advantage of libdbusfat would be applications would not need any 
> change and they would still be able to use DBus, which at the moment 
> is important for cross-desktop interoperability. On Unix platforms, 
> applications would link to libdbus and talk to dbus-daemon. On 
> Windows, Android, etc, applications would link to libdbusfat and talk 
> to the native IPC system.

That would indeed be nice but I fear producing code for that is so much 
work that it will take lot of people a long time :-( The main problem I 
see is that dbus is very flexible and offers lotttt of functionality. I 
think back how much work it was for the KDE at Windows-team to port dbus to 
Windows and that was only porting and not a) changing dbus to work with 
multiple backends and b) get backends done for Windows/OSX/whatever that 
offer all what dbus allows through there native IPC. I think this also 
gives the problem that only applications using dbus could communicate 
with each other on other platforms... in any case I think that is 
*really* a lot of work.

> Of course the QtMobility Publish/Subscribe API could also implement a 
> DBus layer, but it would serve a different purpose (the QtMobility 
> publish/subscribe mechanism is not available from glib/gtk/EFL/etc AFAIK).

iirc publish/subscribe has a gconf-backend and that also shows more for 
what it's used: a interprocess configuration backend that can also be 
used for IPC. That is completely different from what dbus is and offers. 
Personally I think 98% of KDE's dbus use-cases could be done with 
publish/subscribe (excluding the cases that depend on dbus cause the 
daemon offers only dbus).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20120208/99c2712e/attachment.htm>