[SSSD] Design Document: D-Bus Cached Objects

Jakub Hrozek jhrozek at redhat.com
Mon Jun 1 11:24:05 UTC 2015


On Mon, Jun 01, 2015 at 12:31:54PM +0200, Pavel Březina wrote:
> On 05/15/2015 11:30 AM, Jakub Hrozek wrote:
> >On Fri, May 15, 2015 at 11:24:29AM +0200, Pavel Březina wrote:
> >>On 05/15/2015 11:19 AM, Jakub Hrozek wrote:
> >>>On Fri, May 15, 2015 at 11:07:05AM +0200, Pavel Březina wrote:
> >>>>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.
> >>>
> >>>Thanks, one last question, do you think naming the methods just "Store"
> >>>and "Retrieve" is descriptive enough? Would "Cache" and "Uncache" be too
> >>>confusing given that the interface is called "Cache" ?
> >>
> >>Store/Remove as to Store in cache and Remove from cache. Let's compare it:
> >>org.freedesktop.sssd.infopipe.Cache.Object.Cache
> >>org.freedesktop.sssd.infopipe.Cache.Object.Uncache
> >>
> >>org.freedesktop.sssd.infopipe.Cache.Object.Store
> >>org.freedesktop.sssd.infopipe.Cache.Object.Remove
> >>
> >>What does sound better? I think using Cache and Uncache is quite redundant.
> >
> >OK, ACK.
> 
> You made some concerns about name of the attribute and whether it should be
> indexed or not in other thread.
> 
> The attribute is currently named 'cached', my suggestions are:
> a) ifp_cached
> b) ifp_exported

ifp_cached sounds good to me.

> 
> What do you say? Or do you have other suggestions?
> 
> About the index... In my understanding the amount of objects marked as
> cached is supposed to be very, very small in comparison with the total
> amount of users and groups, so we could benefit from the index here.
> However, how often will we need to do the lookup? That depends on the use
> cases and I guess time will tell us. We can add the index anytime later. So
> my call is not add it now.

I think this is the right choice. The index is supposed to be used for
attributes that are used very frequently. I don't think the ifp_cached
attribute will be one of them.



More information about the sssd-devel mailing list