AddMatchWithID / RemoveMatchById

[Havoc Pennington]

Hi,

On Feb 20, 2008 5:18 AM, Simon McVittie <simon.mcvittie at collabora.co.uk> wrote:
> On Tue, 19 Feb 2008 at 20:21:35 -0500, Havoc Pennington wrote:
> > One quick note, I think one library will always own a given socket
> > connected to dbus-daemon
>
> The main reason I'm still considering having dbus-python remain a
> libdbus binding rather than a full implementation (and similar for the
> GLib bindings, potentially) is the bus DBusConnection sharing, so this
> statement makes me somewhat puzzled!
>
> Or are you saying that libdbus will be the "socket owner" for these purposes,
> even if it's things like dbus-glib and dbus-python that actually want to use
> the IDs?

If you understand what I was saying there as I intended it, I don't
think you'll be puzzled - what I was trying to say is more a physical
fact / truism than a proposal, and is not libdbus-specific. What I'm
saying is simply that there can't be two pieces of code that are both
able to send messages down the same socket, and read messages from the
same socket, without some kind of shared, mediating code to keep the
two message senders/readers from stomping all over each other. If two
modules are both reading/writing from the same socket with no
coordination, then the results would be a catastrophe, right? It would
be undefined who read what message, messages would be half-written
then another message interleaved, it would be unknown when to block,
that sort of thing.

So, given that for a single, already-open socket file descriptor,
there must be some shared code that coordinates use of the socket, we
know there is always some shared code that can also coordinate the
match ID namespace. e.g. it could offer an alloc_match_id() type of
operation, or have any other approach.

The API we want for libdbus is a separate question. All I was saying
here is, for _any hypothetically possible_ code module that spoke dbus
protocol (libdbus is one example), it would be reasonable to expect
coordination of the match ID namespace on the client side - that is,
we don't need the daemon to do this and don't need round trips.

Note, the match IDs are scoped to the connection - so if you have two
different dbus client lib implementations in a process, they need not
coordinate match IDs. They only have to coordinate match IDs if they
share the socket file descriptor, which means they are already sharing
some code.

> How are client implementations expected to discover whether the bus
> daemon supports this new functionality? Try it, do the round trip, and
> fall back to the old way if not?

That is a very good question. I think in the past we've discussed
feature negotiation in the auth protocol? I think ideally we would
solve this without adding additional round trips - or at least, if we
add a feature negotiation round trip, it should be extensible so we
don't have a new round trip for each new feature, just a single round
trip to list all features.

If we do nothing the only answer will be to try AddMatchWithID once
and see if an error occurs. That pretty much sucks.

Havoc