directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: [backend] AbstractIdentityBackend interface
Date Wed, 01 Jul 2015 02:57:44 GMT
On Tue, Jun 30, 2015 at 1:37 PM, Zheng, Kai <kai.zheng@intel.com> 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:kayyagari@apache.org]
> Sent: Tuesday, June 30, 2015 11:49 AM
> To: kerby@directory.apache.org
> Subject: Re: [backend] AbstractIdentityBackend interface
>
> On Mon, Jun 29, 2015 at 9:10 PM, Zheng, Kai <kai.zheng@intel.com> 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:kayyagari@apache.org]
> > Sent: Monday, June 29, 2015 5:43 PM
> > To: kerby@directory.apache.org
> > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message