Bug 101899 - Containers (#100344): new header field for container instance
Summary: Containers (#100344): new header field for container instance
Status: ASSIGNED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: git master
Hardware: All All
: medium enhancement
Assignee: Simon McVittie
QA Contact: D-Bus Maintainers
URL:
Whiteboard:
Keywords:
Depends on: 101354
Blocks: 100344
  Show dependency treegraph
 
Reported: 2017-07-24 14:55 UTC by Simon McVittie
Modified: 2017-10-20 18:00 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon McVittie 2017-07-24 14:55:35 UTC
+++ 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.

Design sketch:

* 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).
Comment 1 Philip Withnall 2017-08-01 11:35:18 UTC
(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?
Comment 2 Simon McVittie 2017-10-20 18:00:16 UTC
(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.