[SSSD] Design Discussion: Support for multiple D-Bus interfaces on single object path

Pavel Brezina pbrezina at redhat.com
Tue Nov 11 20:42:49 UTC 2014



----- Original Message -----
> From: "Jakub Hrozek" <jhrozek at redhat.com>
> To: sssd-devel at 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 at redhat.com>
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> 



More information about the sssd-devel mailing list