Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates
 74.125.82.44 as permitted sender)
MIME-Version: 1.0
Sender: akarasulu@gmail.com
In-Reply-To: 
 <CAKjwzkr2AD0wYsbT3snVKmPkaRjf9=V1AAex-xj1BuuJbWpfSQ@mail.gmail.com>
References: 
 <CAKjwzkrubJG+ryJRub3FHVgMX204Zj=dp1KCci=C+Ay+i9cNyA@mail.gmail.com>
	<CAKjwzkr2AD0wYsbT3snVKmPkaRjf9=V1AAex-xj1BuuJbWpfSQ@mail.gmail.com>
Date: Thu, 12 Jan 2012 15:01:29 +0200
Message-ID: 
 <CADwPi+Gf9UadqwULXqWtvRYJhJwq3WONORHGcjM2VZmC7Aj2mg@mail.gmail.com>
Subject: Re: How Authenticators and PasswordPolicies will be managed in new
 component design.
From: Alex Karasulu <akarasulu@apache.org>
To: Apache Directory Developers List <dev@directory.apache.org>
Content-Type: multipart/alternative; boundary=f46d041825cec1769a04b65458e7

--f46d041825cec1769a04b65458e7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 10, 2012 at 2:33 AM, G=F6kt=FCrk Gezer <gokturk.gezer@gmail.com=
>wrote:

> Hi Again,
>
> It seems lots of things are structured like that. Partitions,servers are
> all have inner entries.There are partition-indexes and transports those
> have same problem. I must develop some way to allow such structure.
> Component-hub must have component type specific code to handle these
> things. So i'll work on that before everything. But you can still say if
> Authenticators must be extensible....
>
> Regards,
> Gokturk
>
>
Hi All,

Gokturk and I had a discussion yesterday regarding this topic. Basically
authenticators and password policies can be considered top level
configurable elements unlike indices for example that are specifically tied
to their partitions.

Although Authenticators and PasswordPolicies are managed under the
AuthenticationInterceptor they are top level elements. The
AuthenticationInterceptor just happens to be where functionally their
maintenance made sense in the past. This might change and we might manage
these in the DirectoryService to denote their first class component status.
However PPs and Authenticators are clearly different from a Partition's
Index which is really tied to the partition where as these components are
not really tied the AuthenticationInterceptor.

I think this makes me believe that the AuthenticationInterceptor should not
manage these components but just leverage them by accessing them from the
DirectoryService. The DirectoryService should really manage these top level
components.

Thoughts?

Regards,
Alex

--f46d041825cec1769a04b65458e7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><br><div class=3D"gmail_quote">On Tue, Jan 10, 2012 at 2:33 AM, G=F6kt=
=FCrk Gezer <span dir=3D"ltr">&lt;<a href=3D"mailto:gokturk.gezer@gmail.com=
">gokturk.gezer@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
Hi Again,<div><br></div><div>It seems lots of things are structured like th=
at. Partitions,servers are all have inner entries.There are partition-index=
es and transports those have same problem. I must develop some way to allow=
 such structure. Component-hub must have component type specific code to ha=
ndle these things. So i&#39;ll work on that before everything. But you can =
still say if Authenticators must be extensible....</div>

<div><br></div><div>Regards,</div><div>Gokturk<div><div class=3D"h5"><br></=
div></div></div></blockquote><div><br></div>Hi All,<div><br></div><div>Gokt=
urk and I had a discussion yesterday regarding this topic. Basically authen=
ticators and password policies can be considered top level configurable ele=
ments unlike indices for example that are specifically tied to their partit=
ions.</div>
<div><br></div><div>Although Authenticators and PasswordPolicies are manage=
d under the AuthenticationInterceptor they are top level elements. The Auth=
enticationInterceptor just happens to be where functionally their maintenan=
ce made sense in the past. This might change and we might manage these in t=
he DirectoryService to denote their first class component status. However P=
Ps and Authenticators are clearly different from a Partition&#39;s Index wh=
ich is really tied to the partition where as these components are not reall=
y tied the AuthenticationInterceptor.</div>
<div><br></div><div>I think this makes me believe that the AuthenticationIn=
terceptor should not manage these components but just leverage them by acce=
ssing them from the DirectoryService. The DirectoryService should really ma=
nage these top level components.</div>
<div><br></div><div>Thoughts?=A0</div><div><br></div><div>Regards,</div><di=
v>Alex</div></div>
</div>

--f46d041825cec1769a04b65458e7--