No subject

immutable interface, or it's tied to the empty interface, which is an=20=

aggregation of all interfaces in the object.

The latter case requires run-time introspection and is not recommended,=
 for=20
clear reasons.

> [1] : for example, an object implementing the BlockDevice interface
> will implement the Filesystem interface only if the block device
> actually looks like a mountable filesystem.. and this changes as you
> run wipefs(8) and mkfs(8) on the device.

That's fine. The question is: do we need a generic signal that notifies=
 of the=20
appearance and disapparance of those interfaces?

> > I still have a question which has plagued me for the entire duratio=
n of
> > the PropertiesChanged signal discussion: how do I make sure I'm not=

> > spamming the bus unnecessarily? Some applications may create and
> > destroy objects often -- and properties may change A LOT more often=
 --
> > so how do I know that someone is actually using these signals?
>=20
> My guess is that a lot of new GNOME code is using this since GDBus ha=
s
> support for it and it's easy to use. All my new code is certainly
> using it and udisks 2.0 will use it to a great extent. It will
> actually create a lot less traffic since udisks 1.x current has an
> empty Changed() signal that causes each client to call GetAll()... an=
d
> there's usually at least 2-3 clients per login session.. so...

Even the empty Changed signal may be too much. Imagine the (actual) cas=
e of=20
having exposed to D-Bus a widget, whose position is being animated. Sho=
uld I=20
emit Changed for every pixel it moves?

Moreover, how do I know which objects people are interested in?

My current position is: I will only implement these PropertyChanged sig=
nals if=20
there's a matching subscribe/unsubscribe pattern.

> Anyway, my answer to your question, I guess, is still the same as las=
t
> time this was discussing... I'd solve the problem by extending the
> bus<->app protocol by negotiating a protocol feature during the
> authentication whereby the bus would let the app know what match rule=
s
> it has that applies to the app (including when this set changes). The=
n
> the D-Bus library for the app could be smart about not having to spam=

> the bus if the match doesn't match locally. I'm pretty sure something=

> like that would work and I don't see any apparent race conditions.
> Does that make sense?

Yes. That would be a lot more helpful.

> Either way, I think it's orthogonal to the ObjectManager interfaces
> but, sure, the less traffic and wakeups we can generate, the better!

Not really. To be able to notify of appearance and disappearance of int=
erfaces=20
requires some hooks that currently don't exist which have a performance=
 impact=20
at runtime. I'd rather not enable them unless there's someone intereste=
d.

--=20
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

--nextPart1395345.ubkohUxiKl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iD8DBQBNa9ILM/XwBW70U1gRAshJAKCwtGC9pa33h45ULXyleiInOiWwAACggat1
eSyITh9E66dovGFWxysyYFg=
=8QPO
-----END PGP SIGNATURE-----

--nextPart1395345.ubkohUxiKl--