[SSSD] Design Document: D-Bus Cached Objects

Jakub Hrozek jhrozek at redhat.com
Fri May 15 08:46:30 UTC 2015


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?



More information about the sssd-devel mailing list