directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] Configuration of protocols
Date Wed, 10 Oct 2007 18:35:45 GMT
Ok I had some sleep and low and behold the ideas came to me :).  I think I
have a clear picture of
what we need to do to handle this properly.  Let me describe that here then
try to figure out how
that fits with what you have done and described below.

First if Emmanuel is right about NTP needing both protocol end points on the
same port for both
transport protocols (UDP/TCP) then there is no need to have twice the
configuration. Then
something like these combinations would suffice:

<ntpServer port=123>
   <#directoryService/>
   <#udpAcceptor/>
   <#tcpAcceptor/>
</ntpServer>

Configures both UDP and TCP transports on port 123.

<ntpServer port=123>
   <#directoryService/>
   <#tcpAcceptor/>
</ntpServer>

Configures only TCP on port 123.

<ntpServer port=123>
   <#directoryService/>
   <#udpAcceptor/>
</ntpServer>

Configures only UDP on port 123.

Note that I did not pass in <#apacheDS/> which is not needed since this
service will depend on the
core directory service plus the MINA components.  Depending on which
IoAcceptor is set the respective
transport protocol is used.  If both are set then both transports are to be
used.

So instead of having the NtpServer class just deal with setting up a single
endpoint for one transport
protocol it will handle all endpoints for all transport protocols and no
more configuration bean.  The
component is wired directly but how it's wired determines what is enabled.

If the other protocols obey the same requirements where both transport
endpoints are needed on the
same port then we can follow this same pattern.  We just have to watch for
the special cases if they
do exist.

Now what impact does this have on OSGi and on configuration in DIT for the
future.  I don't know that
yet and it's something to think about.

Ok now inline for discussing your changes ...

On 10/10/07, David Jencks <david_jencks@yahoo.com> wrote:
>
> In rev 583375  I moved all the non-ldap protocol servers into independent
> components and provided 2 NTP implementations as a basis for further
> discussion.
>

Ok so you broke it out to have a UdpNtpServer and a TcpNtpServer which are
in them selves what you
deem one implementation approach I guess right?

Then there is this NtpConfiguration which starts both together as a
configuration bean + manager for the
other two services?

NtpConfiguration illustrates the approach of a single component to configure
> both udp and tcp versions of the same protocol.  This could trivially be
> enhanced with flags to enable/disable the tcp or udp choices.  If we decide
> on this approach I would rename the class NtpServer.
>
> server.xml configuration of this looks like:
>
>   <ntpConfiguration ipPort="80123">
>     <apacheDs>#apacheDS</apacheDs>
>   </ntpConfiguration>
>

Ok then this would be close to what I was pointing out above but it uses
this ApacheDS reference
instead of feeding in the MINA components.  I would like to see these
configuration objects go away
all together without even the ServiceConfiguration base class.  Instead an
AbstractServer object can
be defined and used for server implementations like NtpServer with the base
configuration details in
it.

This way we don't have a configuration bean + additional code to start and
stop subordinate services.
So let me list it out:

AbstractServer (or AbstractService )

    Replaces ServiceConfiguration as base class for protocol servers.  This
is the common
    denominator for all servers running in ApacheDS.  It may need some
properties moved
    into some subtypes since the present ServiceConfiguration has more than
the common
    denominator.

XxxServer

    Takes IoAcceptors.  Some servers need one for each transport some may
only need one.
    Some may take both but optionally.  These protocol servers then manage
binding to the
    appropriate port for the transports.  If somewhere down the line
configurations differ
    dramatically for one transport verses another this model still works.
You can still have a
    UdpXxxServer and TcpXxxServer subtyping the base XxxServer or directly
extending the
    AbstractServer base class.  In these transport specific subtypes they
may only expose
    getter/setter pairs for IoAcceptors for their respective transport.  So
this model is most
    flexible for whatever comes down the pike.

AbstractNtpServer, TcpNtpServer, and UdpNtpServer illustrate the approach of
> a component per protocol version.  server.xml configuration of this looks
> like:
>
>   <udpNtpConfiguration ipPort="81123">
>     <apacheDs>#apacheDS</apacheDs>
>   </udpNtpConfiguration>
>   <tcpNtpConfiguration ipPort="81123">
>     <apacheDs>#apacheDS</apacheDs>
>   </tcpNtpConfiguration>
>

This might not at all be necessary if we attack this problem like the way
suggested above.

I don't have a strong preference between these two approaches and think they
> both are equally good components.  I think the first, single component
> managing both servers, will be easier for our users to understand and
> configure, although it might be conceptually slightly less pure.
>

I think we can do it right and be pure.  We just need to think about it more
but at some point we must stop and
implement it so we're not stuck thinking forever.  This is why your commit
was a great move it helps look at an
example we can take to the next step of the discussion.  Thanks for it.

Whatever the outcome of this discussion I think the next step, other than
> conforming the protocol servers to whatever we decide, is to move the mina
> setup code in ApacheDS into a separate component: this would replace the
> ApacheDS reference in all these servers.
>

Yes this would be good.  I noticed you made these servers dependent on the
server-jndi module just to
pass in the ApacheDS reference.  I'd like to see this dependency go away
where the dependency is really
on the core and MINA components.

More below ...

<OT>

>
> There's an extreme danger here of making a mountain out of a
> > molehill :-)
>
> These comments are counter productive and whether deliberate or not are
threatening to bypass
further reasoning about this matter by trivializing the discussion as being
excessive.  You are entitled
to this opinion but not to shorting this discussion and just doing it some
way.

I'm not trying to force anything and am listening to your suggestions since
I value them.  I pushed to
champion your effort to remove these configuration beans and brought about
the bigbang effort even
though others were worried about it's impact.  This move has pushed out my
personal objectives as
well but we believed in your ideas.  This is why I am following through with
them and trying to do it
to the best of my ability by completely removing these configuration beans.

This is a two way street.  As I extend the benefit of the doubt and patience
you're way you owe me
some patience as well.  Not saying you're not giving it.  But the comment
above is a subtle indicator
that your patience is wearing thin.  When this happens stop and think about
the big step we all took
to meet your wishes.

Also consider that you are new to this project and may not have complete
information to foresee
problems down the line.  On the flip side, you're in a unique position to
really show us how wrong
some of our design decisions are because of your fresh new perspective.
Plus you're not a newbie
and a solid engineer as witnessed by your past contributions.  We know how
incredible you are.

So bear with me because something in the back of my head is telling me to do
this right with
a little more discussion.  We'll get to the bottom of this but let's
consider all our options.

</OT>

Alex

Mime
View raw message