directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: Replication configuration : second thought
Date Mon, 16 Mar 2009 16:10:37 GMT

> 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).
>   
Totally +1. This is why I added them in (). So let's use them exclusively.
>
> Regarding Configuration
> -----------------------------------
>
> 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.
>   
probably
> 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
> more manageable.
>   
That could lead to a centralized configuration in the DiT...
> 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.
>   
In fact, there are _very few_ interceptors that need a configuration :
 - 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.
>   
done
>   (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.
>   
+1
>   (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.
>   
okie
>   (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?
>   
this can be discussed further, as this question is a bit too wide right 
now. Let's use the mechanism we have right now.
>
> 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.
>   
what about having an embedded server with replication capability ?
> 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?
>   
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...)

-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message