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
NtpServer.
server.xml configuration of this looks like:
<ntpConfiguration ipPort="80123">
<apacheDs>#apacheDS</apacheDs>
</ntpConfiguration>
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>
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.
thanks
david jencks
On Oct 9, 2007, at 2:25 PM, Alex Karasulu wrote:
On 10/9/07, David Jencks <[EMAIL PROTECTED]> 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
