<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 02/08/2012 01:30 PM, Pau Garcia i Quiles wrote:
<blockquote
cite="mid:CAKcBokuKJWrdGuxRrFvsaDHd=nn7ShdVgzYGPasjS7W+q8uBCg@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<br>
<br>
<div>On Wed, Feb 8, 2012 at 1:20 PM, Jaroslaw Staniek <span><<a
moz-do-not-send="true" href="mailto:staniek@kde.org">staniek@kde.org</a>></span>
wrote:<br>
<blockquote>
<div>On 8 February 2012 11:50, Pau Garcia i Quiles <<a
moz-do-not-send="true" href="mailto:pgquiles@elpauer.org">pgquiles@elpauer.org</a>>
wrote:<br>
><br>
><br>
> On Tue, Feb 7, 2012 at 3:09 PM, Boudewijn Rempt <<a
moz-do-not-send="true" href="mailto:boud@valdyas.org">boud@valdyas.org</a>>
wrote:<br>
>><br>
>> And yes, well, of course there are platform-local
ways of ipc, on windows<br>
>> and android that we might want to use instead of
dbus, if there is demand<br>
>> for it.<br>
>><br>
><br>
> I talked about this with Holger Schöder at FOSDEM.<br>
<br>
</div>
What's you opinion - where is QtMobility in this which has the
same purpose?<br>
If possible - we sure do not want to have this as KDE-only
thing.<br>
</blockquote>
<div><br>
Are you talking about the Publish/subscribe API? He did not
mention anything.<br>
<br>
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.<br>
</div>
</div>
</blockquote>
<br>
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@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.<br>
<br>
<blockquote
cite="mid:CAKcBokuKJWrdGuxRrFvsaDHd=nn7ShdVgzYGPasjS7W+q8uBCg@mail.gmail.com"
type="cite">
<div>
<div>
</div>
</div>
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).<br>
</blockquote>
<br>
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).<br>
<br>
</body>
</html>