On Tue, Jun 30, 2015 at 1:37 PM, Zheng, Kai <[email protected]> wrote:
> Thanks Kiran for the clarifying. > > >> no, this is a different one that stores all data in a single file in > binary format > >> yes, LDAP backend needs a server, whereas mavibot backend stores > locally on disk > This sounds good. Which one would ApacheDS prefer to use? This one or the > LdapIdentityBackend? > when integrated with ApacheDS it initializes Kerby with LdapIdentityBackend > > >> ic, I see that these doXXX() are for subclasses, but we can completely > avoid these methods, see below > I mentioned cache stuff just as a sample. Even if we get rid of the cache > facility as you suggested, I thought doXXX() methods may still validate. I > meant, for subclasses, they don't have to start with interface no, once we decouple this cache in AbstractIdentityBacken we don't need these doXXX() anymore > methods directly every time, instead internal methods like doXXX(), > because doing the way would allow sharing template codes in the abstract > class. For now, the shared codes are just cache related, later we can > enhance and add more, like parameter checking, exception handling. Please > note this pattern isn't rare, and is widely used across the project. That's > why I still have some concerns for the proposed change (removing them). > there will not be any side effects with this change > > >> This AbstractIdentityBackend ia always utilizing a cache and this is > enforced on all backends that subclass this, instead what we should do is > to create a CacheableIdentityBackend which wraps an instance > IdentityBackend and maintains an internal cache, and calls are delegated to > the wrapped backend when a cache miss happens. > >> This way implementations of IdentityBackend will be free from the side > effects of caching while testing and also become simple and cleaner. > This sounds great!! I'm fine to change and support the cache in this new > way. I thought it's another issue to process. > > this is just part of the design, I will refactor them after finishing the Mavibot backend > How do you think? Thanks. > Regards, > Kai > > -----Original Message----- > From: Kiran Ayyagari [mailto:[email protected]] > Sent: Tuesday, June 30, 2015 11:49 AM > To: [email protected] > Subject: Re: [backend] AbstractIdentityBackend interface > > On Mon, Jun 29, 2015 at 9:10 PM, Zheng, Kai <[email protected]> wrote: > > > Thanks Kiran for the taking. > > > > >> I am implementing a Mavibot based backend*. > > Would you clarify a bit about this? I'm wondering if it's the same > > thing, the on-going LdapIdentityBackend Yaning is working on? > > > no, this is a different one that stores all data in a single file in > binary format > > > Or you mean something that uses Mavibot directly instead of by the > > LDAP connection API? > > > yes, LDAP backend needs a server, whereas mavibot backend stores locally > on disk > > > > > >> Is there any reason why the API methods start with doXXX()? > > I would think AbstractIdentityBackend isn't the interface, and the > > doXXX() methods are not the APIs. > > Please see the APIs in the interface IdentityBackend/IdentityService. > > > ic, I see that these doXXX() are for subclasses, but we can completely > avoid these methods, see below > > > AbstractIdentityBackend is a common abstract class to implement the > > API interface, and provides some useful functionalities like cache. > > > > This AbstractIdentityBackend ia always utilizing a cache and this is > enforced on all backends that subclass this, instead what we should do is > to create a CacheableIdentityBackend which wraps an instance > IdentityBackend and maintains an internal cache, and calls are delegated to > the wrapped backend when a cache miss happens. > > This way implementations of IdentityBackend will be free from the side > effects of caching while testing and also become simple and cleaner. > > > I thought if you don't like it, you could start with totally new, > > implementing IdentityBackend/IdentityService directly. > > > > I hope the above reasons make the intention behind this proposal clear > > > >> now is the time after today's commits in Mavibot trunk that address > > these bugs. > > Glad it's the time now. It will help a lot. > > > > Regards, > > Kai > > > > -----Original Message----- > > From: Kiran Ayyagari [mailto:[email protected]] > > Sent: Monday, June 29, 2015 5:43 PM > > To: [email protected] > > Subject: [backend] AbstractIdentityBackend interface > > > > I am implementing a Mavibot based backend*. > > > > Is there any reason why the API methods start with doXXX()? > > This looks a bit odd and hard to read. > > > > I would like to strip the 'do' verb from these methods, please let me > > know if there are any objections. > > > > * this is on hold for a long time due to the free page management > > bugs, but now > > is the time after today's commits in Mavibot trunk that address > > these bugs. > > > > -- > > Kiran Ayyagari > > http://keydap.com > > > > > > -- > Kiran Ayyagari > http://keydap.com > -- Kiran Ayyagari http://keydap.com
