PropertiesChanged signal, take 2
mzqohf at 0pointer.de
Wed May 12 15:01:23 PDT 2010
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.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the dbus