PropertiesChanged signal, take 2
thiago at kde.org
Wed May 12 15:14:39 PDT 2010
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.
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.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the dbus