-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
My opinion: I would suggest not exposing this concept/code struct
outside of src/sbus/
Callers should just sbus_conn_add_interface(). If two interfaces have
the same object path, it just works ...
Internally when dispatching calls, the interface+path is taken into
account when walking the conn->intf_list.
FWIW, at some point, once you start exporting many many interfaces
(irregardless of which paths they're at) conn->intf_list is ripe for a
hash table of some sort.
Stef
On 13.11.2014 12:43, Pavel Březina wrote:
CC-ing Stef
On 11/11/2014 09:42 PM, Pavel Brezina wrote:
>
>
> ----- 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
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlRk0JkACgkQe/sRCNknZa+kTgCdFDWWJkp0Nu7Hic+krYBK5Ipp
tbwAni/9KuW00j9D2Y+LqWVTGXMBjLDf
=WW/9
-----END PGP SIGNATURE-----