On Monday 19 October 2015 10:59:07 Andy Grover wrote:
On 02/04/2015 03:31 PM, Andy Grover wrote:
> 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 :-)
Hi Alex,
Given the interest that Rancher and QEMU have expressed for integrating
processing of user handlers into their own event loops, it's clear now
that we *do* need to support multiple implementors. The third approach
you describe above is looking very desirable, to present users with a
unified view of what handlers are available.
In that case, one example of successfully using that pattern may be of
interest: the Telepathy instant-messaging framework. Specifically, the
"mission-control-5" acts as a multiplexer in almost exactly that manner to the
various connection managers, each of which handles one-or-more protocols.
One interesting wrinkle is that Oleg from Rancher is already making
progress libifying bits of tcmu-runner. This gives us the opportunity to
implement backend-to-multiplexor coordination in a library that backends
just have to link to and use.
That would certainly be nice!
So...this is turning into a whole big thing after all. I just wanted
to
ping you since we started discussing this back in February, and see if
you had any more advice on how best to proceed, either about the design
or the implementation.
Thoughts?
Are there any other projects we should be using as a model?
As mentioned above, Telepathy is likely the most relevant - especially seeing
as there are libraries, such as telepathy-qt and telepathy-glib, which
similarly abstract over the multiplexing concern.