[SSSD] Design Document: D-Bus Cached Objects

Pavel Březina pbrezina at redhat.com
Fri May 15 09:07:05 UTC 2015


On 05/15/2015 10:46 AM, Jakub Hrozek wrote:
> On Fri, May 15, 2015 at 10:37:06AM +0200, Pavel Březina wrote:
>> On 05/15/2015 10:17 AM, Jakub Hrozek wrote:
>>> On Thu, May 14, 2015 at 02:44:33PM +0200, Pavel Březina wrote:
>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/DBusCachedObjects
>>>>
>>>> Original design is located at:
>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder#Cachedobjects
>>>
>>> Question..
>>> Why did you choose a separate interface and not a Cache() method of the user
>>> object?
>>
>> it depends on the side you are looking from. The way in the design page is
>> easier, but if we want to put it directly on user and group object paths, we
>> can do it for example this way:
>>
>> Interface:
>> org.freedesktop.sssd.infopipe.Cache
>>
>> It will be implemented on:
>> /org/freedesktop/sssd/infopipe/Users
>> /org/freedesktop/sssd/infopipe/Groups
>>
>> Methods will be (or other names):
>> ao List()
>> ao ListByDomain(s:domain)
>>
>> Interface:
>> org.freedesktop.sssd.infopipe.Cache.Object
>>
>> It will be implemented on:
>> /org/freedesktop/sssd/infopipe/Users/$uid
>> /org/freedesktop/sssd/infopipe/Groups/$gid
>>
>> Methods will be (or other names):
>> b Store()
>> b Remove()
>>
>> The advantage is the the caller (and also in sssd) can simply recognize if
>> the cached object is a user or a group without the need to parse the object
>> path.
>
> Right..
>
> Implementing the interface by the objects would feel more natural to me
> API-wise.
>
> Is it a lot more complex to implement? Any other pros or cons?

I have updated the design page.




More information about the sssd-devel mailing list