Re: multiple services per client?
Felipe Gasper <felipe-c4PQK5fb7feI/[email protected]>
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Message-ID | <[email protected]> |
> On Feb 18, 2019, at 8:17 PM, Matt Wette <[email protected]> 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 _______________________________________________ dbus mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dbus