On 7/18/07, Ersin Er <email@example.com> wrote:
First of all, before doing any coding, I think we must stabilize our thoughts on what we need and how we'll do it. So I suggest, before doing any CiDIT stuff in the code, we should document server initialization phase, configurations etc., our needs and solutions at cwiki.
I understand Alex's concerns about the limitations of current approach or limitations that prevent us from doing further enhancements in the way do want but I think the solution suggested is not completely the right way. I agree with most of the comments from Chris and David and here are a few (map be duplication a little bit):
Although LDAP is the right technology to store configuration information,
the proposed solution is not the right way to do this. LDAP is not for structured data.
You cannot define relations between attributes and their values.
(Which is my primary e-mail address? Which organizationalRole is related to which organizationalUnit in my personal entry?) For example, to specify the order of interceptors, using attribute values like n-foo (where n is a positive integer) does not really look elegant.
CiDIT should be just an interface for configuring ApacheDS.
It can even provide some virtual entries.
We should be able to configure ApacheDS in a few ways we want, JMX, LDAP, XML, etc.
BTW, why don't we try to completely abstract this configuration stuff? (For example, Spring can load it's configuration from both XML and property files.)
Many users (developers) are used to configure ApacheDS with server.xml. If this is causing problems in embedded mode, we can also use Java based configuration option (in 2.1+) of Spring.
For the Real dynamic configuration problem, CiDIT does not really have much to do itself. For on-the-fly configuration we need a service manager like OSGi and I think Spring-OSGÝ can be an option there.
Our current design of interceptors do not support any listeners for configuration changes. So it has its own problems.
The dynamic schema generation stuff is, although cool, a dark path.
It's a good research topic on its own but we cannot use it for CiDIT before it gets stable as given example, JDO or JAXB.
Well there are a lot more to say but briefly I can say that we should document our current status, needs and solutions.
Cheers,--On 7/16/07, Alex Karasulu <firstname.lastname@example.org > wrote:Hi all,
Here's that thread on discussing the CiDIT agenda. Let's take a look at the following
link before beginning:
R.A. and Ph.D Student at the Dept. of Computer Eng. in Hacettepe University
Committer and PMC Member of The Apache Directory Project