On Mon, Mar 16, 2009 at 12:10 PM, Emmanuel Lecharny <email@example.com> wrote:
Totally +1. This is why I added them in (). So let's use them exclusively.
Regarding Repl Terminology
OK let's get religious about using replication specific terminology.
Instead of talking about client, server, master, slave, let's use the terms
supplier and consumer. The reason why I like these terms besides their
common use is because it clearly denotes directionality and breaks down
elements of the replication agreements to their atomic components. So I'd
like to think in terms of a consumer configuration (with replication
agreement) and a supplier configuration (also with a repl-agmt).
On a separate note, I've been torn between two ways of thinking about
configuration for some time. Regardless of whether we're talking about
replication subsystem or not, we could apply this general discussion to any
feature/facet of the server which also contains an interceptor. So this
discussion applies across the board as a configuration issue.
That could lead to a centralized configuration in the DiT...
So where do we configure a subsystem? In the interceptor configuration? Or
as a separate component under the directory service. Over the years I've
made many mistakes with this stuff. I like the idea of having a high level
subsystem bean that contains all the configuration for the feature in one
place instead of being distributed all over the configuration tree.
Localization is always good because then the user and developer only needs
to goto one place to get this information or modify the code for it. It's
In fact, there are _very few_ interceptors that need a configuration :
I was always uncomfortable with bloating these interceptors with code.
Instead I just wanted to leave them as simple hooks that funneled events
(calls) into the subsystem. The intercetor is then a simple listener that
belongs to the subsystem in question. So the listener detects events and
shuffles them into the subsystem to properly respond. This allows us to
keep the configuration in the top level subsystem facade while properly
designing the various parts of the subsystem underneath with clarity instead
of jamming all the subsystem handling logic tightly into interceptors which
leads to code bloat in the interceptor modules leading to a jumbled up mess
that is hard to manage.
- Authentication (takes a list of authenticators, something we may want to be global too)
- Journal ( but this is a new interceptor, and the configuration is not yet stabilized)
- Replication, but this is exactly what we are discussing about
and that's it.
So far, there is nothing that prevent us to get rid of any parameter in all the interceptors...
So I recommend the following:
(1) Implement a subsystem for replication with a top level facade bean
that can be configured via XBean.
(2) Setup a means to setup a set of replication agreements. The same DSA
can be both a consumer and a supplier to many other DSAs. So we'll have a
set of consumer agreements and a set of supplier agreements.
(3) Build the interceptor out to be just a simple hook into other Classes
in the subsystem. Make the subsystem return values for LDAP methods in the
chain that require return values.
this can be discussed further, as this question is a bit too wide right now. Let's use the mechanism we have right now.
(4) Don't wory about adding the replication intercetor to the chain via
XBean, just have the subsystem inject the intercetor programatically. The
user does not need to know this interceptor even exists right?
what about having an embedded server with replication capability ?
DirectoryService vs. LdapServer
Now I don't know the answer to this but something itches me about putting
the replication subsystem into the DirectoryService. For some time now the
DS corresponding to the top level facade representing what we always refered
to as the core. The core was never supposed to be networked because then
that would pull dependencies like MINA. It was the frontend that had
network capability. I know mitosis broke from this but seems the moron who
wrote it broke all the rules.
that's a good question... I would tend to think that injecting the replication subsystem into the core server is probably a better way, as it will be available not only to the standalone server, but also for an embedded server (all in all, the networked server just embedded the core...)
Question is do we want replication to be a high level system in the frontend
since it leverages the protocol? Or do we want it in the DS which was
traditionally core services without networking?