PropertiesChanged signal, take 2

Luiz Augusto von Dentz luiz.dentz at gmail.com
Thu May 13 02:33:44 PDT 2010


Hi,

On Thu, May 13, 2010 at 1:14 AM, Thiago Macieira <thiago at kde.org> wrote:
> Em Quinta-feira 13. Maio 2010, às 00.01.23, Lennart Poettering escreveu:
>> On Wed, 12.05.10 23:57, Thiago Macieira (thiago at kde.org) wrote:
>> > Em Quarta-feira 12. Maio 2010, às 21.43.30, David Zeuthen escreveu:
>> > > Hey,
>> > >
>> > > On Wed, May 12, 2010 at 3:00 PM, Luiz Augusto von Dentz
>> > >
>> > > <luiz.dentz at gmail.com> wrote:
>> > > > Hi David,
>> > > >
>> > > > Have you considerer PropertyChanged (only one property)? Afaik match
>> > > > rules only support string matching so we will probably be unable to
>> > > > register signal handlers in a per property basis, which IMO is a much
>> > > > better design than PropertiesChanged which sends many, also at least
>> > > > in BlueZ/ofono/connman Ive hardly see us updating a bunch of
>> > > > properties at once and if that is required it is probably because
>> > > > they should all be grouped together in a single property.
>> > >
>> > > Yes, I considered this but I don't think it's a good idea because it
>> > > makes it makes it impossible to do atomic changesets (e.g. two or more
>> > > properties changing at the same time).
>> >
>> > True, however many automatic emissions of the signal will not be able to
>> > detect the atomic changesets.
>> >
>> > For example, the code I have in mind for QtDBus will always emit this
>> > signal with one entry in the array.
>>
>> Please, don't make this a benchmark for the spec. There are enough
>> lower-level services which really could benefit from atomic prop changes.
>
> Fair enough.
>
> I do think that carrying as much information as possible in one single
> transmission is important. So I am all for using an array.
>
> In any case, if you're caching properties, you're probably caching all of them
> anyway, I doubt the signals would go to waste.
>
> And if the binding fails to detect atomicity, it will still send everything in
> one go, which technically is the same number of wakeups.

One can achieve atomicity by designing the properties correctly, since
each property is supposed to be independent for each other,  and afaik
we can have whatever we want as property since it is variant in the
end. Also if the API depend on the order which the properties are
changed I don't this PropertiesChanged can guarantee any.

-- 
Luiz Augusto von Dentz
Computer Engineer


More information about the dbus mailing list