AddMatchWithID / RemoveMatchById

[Havoc Pennington]

Hi,

On Feb 19, 2008 9:53 PM, Ryan Lortie <desrt at desrt.ca> wrote:
> Imagine the dconf library wants to receive all "notify" signals subject
> to some match rule like /apps/foo/.  It can call some function like
>
> g_bus_match ("[rule for /apps/foo/]", my_callback, user_data);
>
> Someone else (in the same application) wants to make legitimate use of
> dconf's public DBus API and registers a watch on /apps/bar/.
>
> g_bus_match ("[rule for /apps/bar/]", other_callback, user_data);
>

Ah OK, I see what I was missing - the dconf path use case.

I guess the optional-ness of this API means a more traditional
signal-like use case would not take any performance hit here. (Of
course, the current dbus-daemon implementation of match rules is just
a linear list walk anyway, but I'm thinking the ID thing makes a
better implementation more difficult. If only some match rules that
really care about the match ID use the match ID, though, then we're
only (hypothetically) limiting performance when it's useful to do so.)

Something to include in the spec patch is what happens if you try to
remove a match ID rule "by value" - I would suggest it just doesn't
work. i.e. that the ID is effectively part of the "value" so two match
rules, one with and one without ID, do not compare equal for removal
purposes.

I like your idea that 0 means default-sent and that if the header is
missing that means [0]. I would say if the header would be [0] then we
should always leave it out, save some bytes. I don't think [] should
be allowed - does not seem useful to me to know that "this message was
matched by some AddMatch rule" - don't know.

uint32 with 0 having a special meaning already means there's no
"invalid" value, which could be annoying when coding things, don't
know. Perhaps 0 is invalid and 1 means "default sent"?

The spec should probably briefly explain when to use AddMatch vs.
AddMatchWithID; the gist might be "If you mean 'be sure I get this
message if it's sent' use AddMatch; if you mean 'get this message only
if it matches my specific rule' then use AddMatchWithID.
AddMatchWithID is slightly more expensive so is best avoided when not
needed."

The bus daemon will need to enforce that the header is only set by the
daemon (i.e. that one client can't make up a match id header and send
it to another client). This is already done for the sender field I
think, so there's example code.

Does the daemon need to enforce match ID uniqueness? That implies a
walk of all match rules for the connection, right? Maybe a
simpler-to-implement requirement is that the match IDs are ascending -
no recycling. Though that means the client lib can't use an array to
store the callbacks, I suppose.

Perhaps the daemon just doesn't care about duplicate match IDs - a
client that does this is creating problems for itself but maybe not
for the daemon or anyone else... if you re-used a match ID, the daemon
would just require you to remove it twice, and the rules would be
removed in undefined order. No client would do that on purpose, of
course. I'm just wondering if it's worth an O(n) search on adding each
rule just to throw an exception that should never happen (or worth
keeping a hash of all ids in use, alternatively - either way, extra
code just to catch a should-not-happen).

If you write a patch, be sure to patch the spec and include test cases
;-) I would think it's important to test >1 match IDs in the match ID
header, in addition to the obvious test of just 1.

Havoc