directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Embedding Eve Was: To release or not to release?
Date Tue, 23 Nov 2004 19:06:53 GMT
Martin Wegner wrote:


>>A classic place to start is see if the log4j config file can be moved into
>>an LDAP server.  Imagine being able to edit the log4j config file using an
>>LDAP client instead of using a text editor.  And then it can be shared
>>amongst multiple apps (if need be).
Yeah that's one of the massive benefits of using a distributed database 
like LDAP.  Plus the hierarchical aspect works well with log4j's Logger 
hierarchy as well (or was it Categories don't remember).  Anyhow there 
is a good fit here.  Also Enrique in an email below made mention of 
using the Java Preferences API.  The Perferences API is also an ideal 
candidate for being backed by a directory.  Funny thing is I remember 
reading somewhere in the Preferences API documentation about not having 
to use heavy weight facilities like LDAP for storing this kind of data; 
hence the reason for the Preferences API.  I disagree with those remarks 
though - they never knew about Eve as an embeddable lighter wight directory.

Anyhow this is a most excellent topic that only scratches the surface 
for configuration.  Really any peice of information that is...

 o relatively static,
 o needs to be read optimized,
 o highly available for multiple systems to access
 o and might be hierarchical in nature

is an ideal candidate for being backed by LDAP. 

Another very unique fit for LDAP are resource bundles for distributed 
applications.  LDAP filters can use language tags to select attributes 
specific to a partiticular language.  For example I can have a label on 
a webpage where the entry for the label has the following commonNames;

cn;lang-en: hello
cn;lang-fr; bonjour
cn;lang-de; hallo
cn;lang-es; hola

Just asking for cn may default to the language code associated with the 
current locale or the locale of the user making the request.  I could 
explicitely ask for a specific version of the attribute as well such as 
cn;lang-fr.  Plus bundles can go the distance with internationalization 
since LDAP strings are Unicode strings.  There's definately lots of 
synergy here but LDAP has been the child left behind for too long: most 
people have just given up on it unfortunately.

>>The slippery slope of this suggestion is that no one has ever codified a
>>best practices in this area (server config in an LDAP server).  
True no one has done this for the gambit of J2EE application 
configurations or component configurations out there.  This is one of 
the those things this project will have to address and address well.  
IMO having the expertise of folks like Henri and Phil from the commons 
will give us the vision we need to do that right.  People like yourself 
who see this vision are also critical.

>>So my
>>guess is that this group will stir up a number of hornets with this idea. 
>>But that is a good sign.  
Oh I think so.  Look M$ has leveraged the directory in .Net pretty well 
behind the scences to help orchestrate component oriented systems.  The 
open source and Java world has lagged behind in this area for far too 
long.  Almost to a crippling degree.  It's about time we leveraged this 
core technology to help manage and orchestrate our distributed 
components and systems.  Otherwise with the geometric explosion of 
components, users, systems, nodes and much more we're not going to fair 
well in comparision to other technologies already leveraging the directory.

>>If we can get a set of best practices defined
>>(LDAP tree structure, DN construction, live update handling, etc.) then I
>>think the Eve server will have provided a benefit above and beyond the
>>LDAP server.
Great thoughts Marty.  DIT structure and using LDAP properly is 
something that is lacking en mass.  It's pretty hard to make even 
seasoned DBAs see how to contrain and manage a directory information 
tree (DIT).  The key lies in using Schema structures correctly.  One of 
our goals is to make LDAP in general easier to understand and hence 
DIT's easier to design. 

Take for example things like NameForms which define those attributes 
that may be used for the RDN of an entry (structural objectclass) hence 
effecting the possible DNs within your DIT namespace.  Many people just 
don't know about these things.  I guess we are going to have to 
predefine schemas for the configuration stuff to make sure they don't 
have to grok these concepts to store simple configurations in their 
directory.  In the end though I don't want to dumb it down to the point 
where things are not intuitive.   Directory users should not loose power 
for ease of use.

So yeah if we can overcome these hurdles gracefully we can really make a 
big impact to the OS community and especially the Java community.  These 
and other reasons (i.e. lack of LDAP triggers) are the driving forces 
behind the genesis of the Directory project.


View raw message