On 02/08/2012 01:30 PM, Pau Garcia i Quiles wrote:
On Wed, Feb 8, 2012 at 1:20 PM, Jaroslaw Staniek <stan...@kde.org
<mailto:stan...@kde.org>> wrote:
On 8 February 2012 11:50, Pau Garcia i Quiles
<pgqui...@elpauer.org <mailto:pgqui...@elpauer.org>> wrote:
>
>
> On Tue, Feb 7, 2012 at 3:09 PM, Boudewijn Rempt
<b...@valdyas.org <mailto:b...@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@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).
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
