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

Pavel Březina pbrezina at redhat.com
Thu Nov 13 11:43:07 UTC 2014


CC-ing Stef

On 11/11/2014 09:42 PM, Pavel Brezina wrote:
>
>
> ----- 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
>>
> _______________________________________________
> 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