[SSSD] Design Document: D-Bus Cached Objects

Pavel Březina pbrezina at redhat.com
Fri May 15 08:52:22 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?

It will take more code, but IMHO it is actually easier to implement 
since you will deal with both object types separately.





More information about the sssd-devel mailing list