From: "Jakub Hrozek" <jhrozek(a)redhat.com>
To: sssd-devel(a)lists.fedorahosted.org
Sent: Tuesday, November 11, 2014 9:04:23 PM
Subject: Re: [SSSD] Design Discussion: Support for multiple D-Bus interfaces on single
object path
On Tue, Nov 11, 2014 at 08:34:04PM +0100, Jakub Hrozek wrote:
> On Tue, Nov 11, 2014 at 05:55:57PM +0100, Pavel Březina wrote:
> >
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusMultipleInterfaces
>
> For convenience, I'm pasting the full design page text below:
>
> = Support for multiple D-Bus interfaces on single object path =
>
> Related ticket(s):
> * [
https://fedorahosted.org/sssd/ticket/2339 IFP: support multiple
> interfaces for object]
>
> == Problem Statement ==
>
> Currently our D-Bus implementation supports having only one interface
> registered per one object path prefix. This can be rather limiting feature
> since it is often useful to separate shared methods and properties under
> one interface that can even have the same implementation for different
> object types. This will soon become a serious drawback when the Infopipe
> starts supporting signals and new objects. SSSD already supports few
> specialized interfaces such as DBus.Properties and DBus.Introspectable but
> those are currently hardcoded to the S-Bus dispatching logic which can be
> avoided with direct support for multiple interfaces.
>
> == Current state ==
>
> The D-Bus interface in the !InfoPipe is defined by a sbus_vtable structure
> and associated with a single object path or an object path prefix followed
> by '*' wildcard. For example the current list of !InfoPipe interfaces
> looks as follows:
>
> {{{
> static struct sysbus_iface ifp_ifaces[] = {
> { "/org/freedesktop/sssd/infopipe", &ifp_iface.vtable },
> { "/org/freedesktop/sssd/infopipe/Domains*", &ifp_domain.vtable
},
> { "/org/freedesktop/sssd/infopipe/Components*",
&ifp_component.vtable
> },
> { NULL, NULL },
> };
> }}}
>
> There is only one allowed wildcard '*' and if present it has to be the last
> character of the object path.
>
> The dispatch logic is:
>
> 1. Lookup the vtable by object path from the message
> 2. Check that the interface name is the same as the interface define in the
> message, if not check if the interface in the message is one of the hard
> coded interfaces
> 3. Fail if the interface is invalid
> 4. Find and execute the method handler
>
> == Proposed solution ==
>
> The structure sysbus_iface combines an object path (pattern) and a list of
> supported interfaces on this object path.
>
> There can still be only one supported wildcard and that is '*' but it is
> possible to use it everywhere and multiple times in one object path.
>
> The dispatch logic is:
>
> 1. Acquire interface and object path from D-Bus message
> 2. Find an object path pattern that matches the object path from the
> message, if more than one such pattern exist then the first one defined is
> used
Can you remind me (sorry, I don't remember the code anymore and I'm busy
with other work atm) if these structures are generated? If so, then
first match sounds a bit dangerous, just moving around some code or
changing the codegen would make sssd use a different interface.
No, this is outside the generated code. I don't expect any changes in the codegen.
Should we use some 'best match' instead (more wildcards
matched or
something like that) ?
I thought about that but I think it is not worth it to code a best match algorithm. At
least not at the moment. I would rather wait until the InfoPipe is more mature so we can
say what approach is the best for such algorithm since you can define best match in
several ways.
> 3. Find a list of interfaces associated with this object path pattern, if
> not found continue with next pattern that matches
> 4. Execute a message handler that is associated with both object path and
> interface
It would be helpful if you could provide an example like above, I'm
afraid it's not easy for me to visualize the matching flow.
>
> == Authors ==
>
> * Pavel Březina <pbrezina(a)redhat.com>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel