AddMatchWithID / RemoveMatchById

[Ryan Lortie]

Hello.

I would like to discuss some changes to the bus daemon.  I propose that
something like the following API is added to the bus:

AddMatchWithID (in STRING rule,
                in UINT32 id)           throws "ID already exists" error

RemoveMatchByID (int UINT32 id)         throws "no such ID" error

I propose also, that a header field be added to the D-BUS protocol.

"""

MATCH_IDS    9       ARRAY OF UINT32     optional

If this optional field appears then it lists the match IDs that caused
this message to be delivered to the client.  This field is only set by
the message bus.  Messages sent through the bus with this field set will
have the field removed and possibly replaced.

"""

Note that the specification clearly states that header fields that are
not understood are simply ignored so this wouldn't break anyone.  Also
note that maybe this field would never be set by the bus except in the
case that the client called AddMatchWithID anyway.

These changes would allow a client-side library to know to which user
function a signal ought to be reported.  It removes the burden of the
client library recomputing the match rules for itself.  It also removes
the requirement that the client maintain its own matching code and track
changes to the server-side match code (like the recent path matching
changes).

A client library could then register all matches with AddMatchWithID and
know where to send the signals.



This approach requires slightly more processing on behalf of the server.
It can no longer stop at the first match rule that allows a message to
be sent -- it has to process the entire list in order to produce the
list of match IDs.  On the flip side of that, however, the client has to
do absolutely no searching of its own so overall processing is reduced.



I'm not sure what the situation should be for messages that are matched
with rules but would have been sent to the client already anyway (for
example, because they were explicitly addressed to the client).  I
imagine something like the following could occur:

  - '0' is a reserved match ID that means "delivered by default". 

  - if the MATCH_IDS field does not appear in the header then it implies
    a value of [0], and not of [] (ie: "you are receiving this message
    because it was delivered by default).

  - what does [] mean?  see below.

  - if a message is sent both by default and by explicit rule (ID #42)
    then MATCH_IDS would be sent, set to [0, 42]

This would allow something in a process to register a match on all
messages and still have them processed properly by the library's
"default routing" rules (because of the appearance of ID #0).

Having [] as your MATCH_IDS field is conceptually invalid if you've
never called AddMatch (without ID) since this means that you're
receiving a message for no reason at all (no default deliver "ID 0" and
no other matching rule ID).  With AddMatch (no ID), though, [] could
mean that you're receiving the message because of an AddMatch (and there
is no '0' here because it wouldn't have been delivered by default).  But
maybe we just want to avoid sending the extra field unless a client has
explicitly sent a AddMatchWithID message (indicating that they
understand this field's meaning).



Something worth considering is perhaps letting the bus assign the ID
numbers.  This removes the possibility of a "ID already exists" error.
It also allows things to remain sane in the case that a user sidesteps
their client-side library and calls the AddMatchWithID function directly
(since they won't have to guess which IDs are unused or not).  It makes
writing the client library slightly more difficult since it would need
to get the reply from the server in order to know the ID number but this
isn't too bad.


I'd like feedback and refinement of my ideas.  As far as writing the
code goes, I can do that for myself :)


Cheers