GNU bug report logs - #43252
27.1; DBus properties lack type hints or overrides

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Hugh Daschbach <hugh <at> ccss.com>
Cc: 43252 <at> debbugs.gnu.org
Subject: bug#43252: 27.1; DBus properties lack type hints or overrides
Date: Mon, 07 Sep 2020 20:00:43 +0200

Hugh Daschbach <hugh <at> ccss.com> writes:

Hi Hugh,

>>> There doesn't seem to be any mechanism to register the property and
>>> have
>>> introspection describe it as as an :object-path.
>>>
>>
>> Confirmed. In `dbus-registered-objects-table', properties are stored
>> w/o
>> signature. An object path is stored as string, and dbus-get-property
>> returns a string.
>>
>> Introspection data could be used if exists (like in your case). But
>> they
>> are optional, so one cannot trust on their existence. Maybe we could
>> say
>> that, in absence of introspection data, ofD.Properties.Get and
>> ofD.Properties.GetAll shall return a default type, like string in
>> case
>> of object paths? Then it would be the responsibility of the user to
>> provide proper introspection data if needed.
>>
>
> I had considered an optional or keyword argument to
> dbus-register-property, but I like introspection even more.  Then the
> application simply registers ofD.Introspectable.Introspect for each of
> its objects?

I'm just sitting at this. Yes, introspection data is the best way to
go. I've already extended dbus-introspect-get-signature to support also
properties (it does already work for methods and signals, modulo a bug I
have fixed this way). Looks promising.

> Introspect returns XML.  The SEXP that dbus-introspect-xml returns is
> easier to work with.

Sure. But there are several helper functions, like the just mentioned
dbus-introspect-get-signature. Have a look at dbus.el; not everything is
documented. (And since I'm bad in documentation; comments for
improvements are appreciated)

> So do you memoize the returned value?  There may not be enough
> overhead to be concerned.  I'm just trying to imagine what overhead
> would be introduced.

Not yet. But in case of performance problems, we could indeed do caching.

> I'm looking at emulating a Bluetooth keyboard.  So I'm anticipating
> bursty property updates on the order of tens per second.  User
> initiated, rather than continuous background activity.  But I don't
> want to bog the system down.  An introspection per property update
> probably isn't much to worry about.

My experience is that method calls are very responsive. But I haven't
tested with bulk data yet, we'll see.

Another problem: The changes I apply do not qualify as bug fixing any
longer, so I fear they are not applicable to Emacs 27. I'm working on
Emacs' master branch (what will be Emacs 28 later), the patches I have
provided to you were backports. Do you have a chance to use Emacs'
master branch? This will avoid discussions with the maintainers whether
those changes are good for Emacs 27, and it will simplify my life
considerably, because the sources for D-Bus in Emacs 27 and 28 differ. I
have even applied changes to dbusbind.c, which means it would be harder
for you to integrate my patches into Emacs 27.

> Cheer,
> Hugh

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.