https://fedorahosted.org/sssd/wiki/DesignDocs/DBusCachedObjects
Original design is located at: https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder#Cachedobjects
The new design page is supposed to be more descriptive. I also took the opportunity and renamed the methods, lets see if you like it.
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?
The new design page is supposed to be more descriptive. I also took the opportunity and renamed the methods, lets see if you like it. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
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.
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?
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.
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.
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" ?
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.
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.
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
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.
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@lists.fedorahosted.org
-
Jakub Hrozek -
Pavel Březina