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