directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [ApacheDS] Configuration of protocols
Date Wed, 10 Oct 2007 07:48:06 GMT
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.

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  

server.xml configuration of this looks like:

   <ntpConfiguration ipPort="80123">

AbstractNtpServer, TcpNtpServer, and UdpNtpServer illustrate the  
approach of a component per protocol version.  server.xml  
configuration of this looks like:

   <udpNtpConfiguration ipPort="81123">
   <tcpNtpConfiguration ipPort="81123">

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.

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.

david jencks

On Oct 9, 2007, at 2:25 PM, Alex Karasulu wrote:

> On 10/9/07, David Jencks <> wrote:
> NTP is pretty darn simple and I'm going to code up a couple of
> examples using it so we can better see what we are talking about.
> NTP is simple and one of the reasons why I picked it for the  
> example.  Also as you
> say it can be used for a simple experiment to see the impact of  
> what we want to do
> without a massive investment in time.
> On the other hand although NTP is the easiest to understand the  
> same reasoning may not
> apply to the other protocols.  Enrique understands these best so he  
> might have something to share
> about it.  Knowing that he's not on IRC I made sure he got wind of  
> it by posting it here.
> There's an extreme danger here of making a mountain out of a
> molehill :-)
> Well the plan was simple: get rid of the configuration beans and  
> directly wire up the components.
> As I said this was your idea and a damn good one.  I just don't  
> want configuration beans floating
> around with one exception here and one exception there.
> Let's set a standard pattern to follow and stick to it.
> Alex

View raw message