Questions ad using GDBus instead of libdbus (Re: Fwd: Re: Race condition in send_with_reply_and_block()

[rony]

Hi Simon,

thank you for your comments. I take from them that libdbus is somewhat a proof-of-concept reference
implementation, whereas GDBus is somewhat more a "real-world" implementation than libdbus,
especially w.r.t. multithreading and better maintained?

---

You have been suggesting from time to time to switch to/use GDBus. So maybe a few questions from
someone who has no working knowledge of it and the environment it needs in order to execute:

  * Can GDBus be used without a message loop?
  * What infrastructure is needed to be able to run GDBUs on AIX, Linux, MacOSX, Windows? Are there
    maybe stand-alone packages for installation on these systems (and for the Windows world, maybe
    precompiled binaries)?
  * What do you expect GDBUs' lifetime will be (how long would it be developed, maintained)?
  * How big of an effort do you think it will be to port a libdbus language binding to GDBUS (took
    me quite some time to dig into the libdbus APIs and debug the binding, hence another reason for
    me to be inclined to stick with libdbus, if possible at all)?

TIA for any insights, hints, pointers, suggestions, warnings ;) !

---rony



On 23.07.2013 14:47, Simon McVittie wrote:
> On 22/07/13 20:35, rony wrote:
>> A few years ago, studying the DBus specifications I have come to believe that libdbus is the
>> official reference implementation, not GDBus
> libdbus is the reference implementation. That means that if its
> interpretation of the D-Bus Specification conflicts with (for instance)
> GDBus' interpretation, libdbus is probably right; but that's all that
> being a reference implementation implies. It does not mean it is the
> fastest or highest-quality implementation, the easiest-to-develop-with
> implementation, or the implementation that interacts best with other
> system features (such as multi-threading or various main loops).
>
>> I have been expecting
>> that any errors the reference implementation has will be fixed over time.
> Errors will only be fixed if someone fixes them. All of the D-Bus
> maintainers primarily work on other things, and have a limited amount of
> time we can spend on it - in an ideal world, we'd be able to devote a
> lot of time to making libdbus perfect, but this is not an ideal world.
> My assessment is that we could spend a massive amount of time on trying
> to perfect multi-threading and still not get there, so I would prefer to
> spend my D-Bus time fixing things that have a better "return on investment".
>
>> how
>> libdbus does multithreading is not really comprehensible
> Adding correct multi-threading to code that has not been designed for
> multi-threading "from the ground up" is rarely comprehensible - this is
> not unique to libdbus. :-)
>
>> As long as GDBus is not the official reference implementation for DBus being available on all major
>> operating systems (including Windows and MacOSX), I feel forced to stick to libdbus
> Please do not feel forced to stick to libdbus. Being the *reference*
> implementation does not mean that it is the *best* implementation.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20130723/492b3f6c/attachment.html>