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. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
