On 02/04/2015 12:21 PM, Alex Elsayed wrote:
Maybe we step back and define a DBus interface
I'd be quite happy with that - I considered suggesting it, in fact, but
wasn't sure of the prevailing opinion re: dbus around here.
What would you do re: discovery, though?
(Explaining some DBus things, which readers may already be aware of)
In DBus, there's a two-level hierarchy of busnames holding objects.
Busnames are either the inherent, connection-level one of the :\d+.\d+ form,
or the human-readable well-known name form (reverse DNS). Objects, then,
implement interfaces.
However, well-known names can only have a single owner - so discovering
which busnames have objects which implement an interface is non-trivial.
The approach taken by KDE is to suffix the well-known name with the PID
(org.kde.StatusNotifierItem-2055 or whatever), call ListNames, and filter in
the client. This has the drawback of making DBus activation impossible.
Another approach is for every implementor to try to claim the well-known
name, and on failure contact the existing owner to republish their objects
(possibly under a namespaced object path). This has the drawback of
complicating the implementation somewhat, as well as making bus activation
only able to activate a single 'default' implementation.
A third approach would be to explicitly define a multiplexor, which backends
ask to republish their objects. This simplifies implementations, and it
could also provide its own API that requests a backend by name, and ensures
that backend's object is available. This could be driven by something as
simple as a key-value mapping from backend name to a well-known DBus name
specific to that backend, which the multiplexor calls to trigger service
activation.
Thoughts?
It really seems to come down to: will multiple independent user-handler
daemons be needed? Because I'm trying really hard to make tcmu-runner
good enough so that the answer is no :-)
tcmu-runner supports multiple handler modules, so it's extensible. It is
permissively licensed so no issues with non-FOSS handlers needing their
own daemon. It also could be replaced entirely (either with a modified
version of itself or from scratch) and still not give up the
single-busname, service activation approach.
So that would be my current preference. (The fact that the kernel API
doesn't preclude multiple handler daemons does not mean we need to
*support* those right away, or ever.)
If there are likely use cases that tcmu-runner is unsuitable for solving
by itself then that would change things of course, and let's please talk
about them!
-- Andy
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
