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

Previous Next

Full log

Message #80 received at 43252 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Hugh Daschbach <hugh <at> ccss.com>
Cc: 43252 <at> debbugs.gnu.org
Subject: Re: bug#43252: 27.1; DBus properties lack type hints or overrides
Date: Fri, 18 Sep 2020 11:36:17 +0200

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

Hi Hugh,

>> Implementation is more complex than expected. Due to its nature,
>> org.freedesktop.DBus.Monitoring.BecomeMonitor requires another
>> (parallel) connection to the bus. This is not foreseen yet in
>> dbusbind.c;
>> will see how it could fly.
>>
>> What I could provide just now is an implementation which runs in
>> *another* Emacs instance. This could be used for monitoring only,
>> because it is another connection to the bus per definition. Are you
>> interested to get such a partial implementation?
>
> I'm interested in whatever you want to implement.  I see signature
> verification useful for testing rather than an exposed feature.
>
> From what I can see from looking at dbus-monitor output the correct
> property types are being exposed now.  It seems to be working.
>
> So whatever we approach we take, the benefit is early warning of
> future
> regressions.  You are a better judge of benefit of additional effort
> than I.
>
> A second Emacs instance seems to offer the same asynchronous output
> gathering issues that dbus-monitor poses.  It does eliminates the
> ad-hoc
> parser.
>
> If you have a longer term goal, I'd suggest pursuing that rather than
> something partial that you'll want to replace later.
>
> But I have no objection to a parallel instance to gather request
> signatures.

I don't know where we end up. I'm still poking around how to implement a
second connection to the same bus. If it is not too expensive to
implement I'd prefer this.

> Which raises the question, should dbus-set-property function call fail
> for a local property that isn't :readwrite, or should that only be
> prevented by incoming messages?

dbus-set-property doesn't know, whether a property is registered
locally. I guess an error reply is reasonable, whether the property is
registered locally, or not.

> Do we require that dbus-register-property be used to update a :read
> access property.

dbus-set-property shall fail when the property has :read access. Yes,
such a property can be changed only by dbus-register-property. But :read
access is intended to tell the clients, that they shouldn't change the
property; an error in dbus-set-property (returning nil, respectively) is
appropriate.

> Cheers,
> 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.