Making dbus optional in Calligra

[Jaroslaw Staniek]

On 8 February 2012 15:56, Pau Garcia i Quiles <pgquiles at elpauer.org> wrote:
>
> On Wed, Feb 8, 2012 at 3:45 PM, Jaroslaw Staniek <staniek at kde.org> wrote:
>
>>
>> >> > 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.
>>
>> This but also the service framework wraps dbus services:
>> http://doc.qt.nokia.com/qtmobility/qtserviceframework.htm
>> http://doc.qt.nokia.com/qtmobility-1.2/service-frameworks.html
>>
>> +it's ported
>> http://doc.qt.nokia.com/qtmobility-1.2/index.html#platform-compatibility
>>
>
> Would this allow Qt applications to use DBus services (Secret Service,
> MPRIS, etc) without a dbus-daemon?
>
> (I've only quickly skimmed over the documentation and it seemed like Qt
> Service Framework uses QtDBus, which would talk to dbus-daemon, for DBus
> services)

I see that your idea addresses slightly different requirements and
touches different layers, thus is also different in terms of
deployment and maintenance.

If e.g. Secret Service cannot be useful without DBus, then it has no
place on platforms that use other means than DBus, it's simple.... I
see no reason to fix it outside of Secret Service itself.

DBus was not designed as _that_ generic abstraction. Various IPC
mechanisms do not map to it well because of behavioral differences.
Nobody is to blame here.

The Qt Mobility's Service Framework solution does not put DBus on
platforms where replacements are present. It uses the fact that many
current mobile platforms have the replacement. This model and use
cases are most probably be used by Calligra apps that are not really
heavy users of dbus.

As a contractor who worked on windbus long ago I am convinced I would
use the time for more valuable tasks.
I wasn't delight when noticed Kontact Mobile on WinCE use dbus
(however that was perhaps because WinCE limitation). I would be
dissatisfied to see dbus pushed to other platforms instead of
integration. There is always temptation of not changing app source
code but instead altering the original platform architecture with
redundant services. I disagree with this approach which reminds me
Google's own Engineering [tm] by pushing Wine-based app layer on
Linux: Linux Desktop programming using Wine and Win API (see Google
Picasa).

The place to alter is, if needed, QtDBus with its tools. Maybe this
was already largely done in Qt Mobility, more checking is needed. I
have no problem with replacing QtDBus use with something higher level
in code meant to be portable beyond platforms that use DBus.

Also, IIRC Android devs know DBus can be present on system but this is
implementation detail. I see no need to expose this detail in a form
of common public API.

-- 
regards / pozdrawiam, Jaroslaw Staniek
 http://www.linkedin.com/in/jstaniek
 Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
 KDE Software Development Platform on MS Windows (windows.kde.org)