PropertiesChanged signal, take 2

[Thiago Macieira]

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.
-- 
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
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20100513/b88266a1/attachment.pgp>