Being interested in NameOwnerChanged for a namespace, not one name
Lennart Poettering
mzqohf at 0pointer.de
Sun Sep 19 14:40:04 PDT 2010
On Fri, 17.09.10 08:23, Marcel Holtmann (marcel at holtmann.org) wrote:
> Hi Will,
>
> > Mission Control, a Telepathy component, watches for new Telepathy
> > Connection Managers appearing by binding to NameOwnerChanged and looking
> > for names starting with "org.freedesktop.Telepathy.ConnectionManager.".
> >
> > So obviously this is a bad idea. ryan lortie rightly called me out for
> > this at GuadeKademy last summer, and I started implementing support for
> > argXprefix in match rules:
> > <http://git.collabora.co.uk/?p=user/wjt/dbus.git;a=commitdiff;h=refs/heads/argx-prefix-matching>.
> > I haven't worked on it since then, but have just been reminded of it.
> >
> > Any opinions on whether:
> >
> > • this is a good general approach to solving this problem;
> > • this is a good specific approach to solving this problem;
> > • support for this should be negotiated at connection time, or inferred
> > by the error reply from AddMatch, or included in a list of features
> > pushed to the client by the bus just after connection (as suggested by
> > Alban on IRC), or...?
>
> what is wrong with just adding glob style pattern matching to the arg0
> argument? Or to AddMatch arguments in general. It seems a bit more
> straight forward to me. Just doing prefix matching also seems a bit
> short sighted to me. What is if some application requires suffix
> matching or wants some specific middle part?
I had a similar thought when I read Will's mail first. However, I then
came to the conclusion that prefix matching is what we want here,
because it's the one scheme that makes sense with the way dbus names are
build.
Or to put it in other words: i believe allowing more flexible matching
here might get people to name their services "foo.$something.bar"
instead of "foo.bar.$something", which I believe we should avoid and
hence not encourage by more flexible name matching.
Lennart
--
Lennart Poettering - Red Hat, Inc.
More information about the dbus
mailing list