----- Original Message -----
> 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
>
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel