+++ This bug was initially created as a clone of Bug #100344 +++
See Bug #100344.
After the basic implementation (Bug #101354), we want an easy, cheap way for the dbus-daemon to tell services like dconf "this message came from container instance /.../c23". If dconf already knows about c23, it can short-cut to just doing the right thing; if not, it will have to call GetInstanceInfo("/.../c23") before deciding what to do with the request.
* New method on the bus driver, o.fd.DBus.C1.RequestContainerHeaders() or
o.fd.DBus.RequestHeaders(["o.fd.DBus.Containers1"]) or similar. If this
method call succeeds, the dbus-daemon will add CONTAINER_INSTANCE to every
unicast message sent to the connection that called the new method.
* Open question: Do we need this for broadcasts too? If yes, we
would have to either run the matchmaker *before* sending the message
to the addressed recipient (at the moment it's after), so that we could
edit the message header; or copy the message, add the header and send
the copy instead of the original.
* New header field, CONTAINER_INSTANCE, of type OBJECT_PATH.
If present with value "/", this message did not come from a container.
If present with any other value, this message came from that container
instance. If not present, we make no particular statement about that.
* If we need this for broadcasts too, we might have to say:
The message bus may add this field to messages even if the recipient
did not ask for it (as an optimization for the case where a different
recipient did ask for it).
(In reply to Simon McVittie from comment #0)
> * If we need this for broadcasts too, we might have to say:
> The message bus may add this field to messages even if the recipient
> did not ask for it (as an optimization for the case where a different
> recipient did ask for it).
Doesn’t that negate the point of adding RequestHeaders() in the first place, since the header is now potentially being sent to connections whose client library doesn’t understand it?
(In reply to Philip Withnall from comment #1)
> Doesn’t that negate the point of adding RequestHeaders() in the first place,
> since the header is now potentially being sent to connections whose client
> library doesn’t understand it?
I think that's fine: the point of adding RequestHeaders() in the first place was optimization, not lack of client library support. Client libraries are already required to ignore header fields they don't understand.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.