multiple services per client?

[Felipe Gasper]

> On Feb 18, 2019, at 8:17 PM, Matt Wette <matt.wette at gmail.com> wrote:
> 
> I am no dbus expert, but ...
> 
> You could represent services as well known (factory) paths, and fork off instances of
> those if needed?  For example /org/me/textservice /org/me/imageservice, and maybe
> these both provide the org.me.Explore interface.  In the end, if I understand correctly,
> you are sending a message to a destination and that destination is identified by
>  (optional) bus name (aka destination), path name, interface name, and member.  The
> member must be an element of the interface.  The degree of freedom is the path name.
> If you have server state associated with a interaction, then use the well known path to
> generate an instance (e.g., "new" message to textservice generates a new object
> testservice1).

I’m using “destination” in the strict D-Bus sense of the term, which is just the D-Bus endpoint where the daemon sends the message, irrespective of the object path, interface, and member. By “service”, I mean basically an application with a well-known name (i.e., from RequestName) on D-Bus.

What I’m asking about is routing D-Bus messages at the destination endpoint based on the DESTINATION that the sender specifies. While it’s trivially possible to offer diverse functionality from a single D-Bus client (e.g., via multiple objects, multiple interfaces on the same object, etc.), the fact that the D-Bus daemon does not send the originally-given DESTINATION header excludes the specific workflow that I envision. A D-Bus endpoint that claims multiple well-known names would thus only have use for those names as aliases of each other.

And that’s fine--this was a purely theoretical inquiry. It’s not hindering anything I actually *want* to do with D-Bus. :)

I *am* curious, though, whether the specification as it is necessitates the D-Bus daemon’s behaviour of “normalizing” the DESTINATION header, or if this is something that another daemon implementation could potentially do differently.

-F