directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Configuration again ...
Date Sat, 16 Oct 2010 10:18:37 GMT
  On 10/16/10 10:28 AM, Kiran Ayyagari wrote:
> hi Emmanuel,
>
> On Sat, Oct 16, 2010 at 5:41 AM, Emmanuel Lecharny<elecharny@gmail.com>  wrote:
>>   Hi guys,
>>
>> considering we want to store the config the way Stefan suggested, ie :
>>> DirectoryService
>>> ->    Partitions
>>>      ->    Indexes
>>> ->    Journal
>>> ->    Changelog
>>> ->    Servers
>>>      ->    LdapServer
>>>          ->    Transports
>>>          ->    Replication consumer
>>>          ->    Replication provider
>>>      ->    KerberosServer
>>>      ->    ...
>> we will need some refactoring in the config OC ad DIT structure.
>>
>> For instance, for a specific DS (with a specific ID), we will have the
>> following DIT :
>> ou=config/
>>   ads-directoryServiceId=myDS/
>>   ads-directoryServiceId=myDS.ldif
>> ou=config.ldif
>>
>> ou=config being the root for all the configuration
>>
>> The ads-directoryServiceId=myDS.ldif file will contain all the config for
>> myDS DS, except the data stored into the ads-directoryServiceId=myDS
>> directory.
>>
>> In this directory, as myDS will have partitions, interceptors, servers, we
>> will have :
>>
>> ou=config/
>>   ads-directoryServiceId=myDS/
>>     ou=ads-servers/
>>     ou=ads-partitions/
>>     ou=ads-interceptors/
>>     ads-changeLog=myCL.ldif
>>     ads-journal=myJournal.ldif
>>     ads-passwordPolicy=myPolicy.ldif
>>
>> the ldif will contain all the elements for the journal, changeLog and
>> passwordPolicy, and they are LDIF files because the DS OC has those elements
>> as SINGLE-VALUED ATs. For the partitions, servers and interceptors, as they
>> are MULTI-VALUED, we have one intermediate level, described by the
>> ou=ads-servers, ou=ads-partitions and ou=ads-interptors.
>>
>> the so rule is quite simple :
>> - if a Bean OC has single valued composite AT, like Journal or ChangeLog,
>> then the associated informations are stored into a ldif file one level
>>   below.
>> - if a Bean OC has multi-valued composite AT, like partitions or
>> interceptors, then we will find the associated ldif files under an
>> ou=<attributeName>  branch, so 2 levels below. as we store the ID of such
>> elements, it will be easy to retrieve them with a lookup.
> this structure completely defeats the current idea of keepin all
> config in single file

The structure I describe is the *exact* structure we currently have... 
If it defeats the current idea we have, then what we have is actually 
completely wrong :)

ou=config/
   ads-directoryServiceId=default/
     ou=interceptors/
       ads-interceptorId=aciAuthorizationInterceptor.ldif
       ads-interceptorId=authenticationInterceptor.ldif
       ...
     ou=partitions/
       ads-partitionId=example/
         ou=indexes/
           ads-indexAttributeId=1.3.6.1.4.1.18060.0.4.1.2.1.ldif
           ...
         ou=indexes.ldif
           ads-indexAttributeId=1.3.6.1.4.1.18060.0.4.1.2.1.ldif
           ...
       ads-partitionId=system/
       ads-partitionId=example.ldif
       ads-partitionId=system.ldif
     ou=interceptors.ldif
     ou=partitions.ldif
   ads-directoryServiceId=default.ldif
ou=config.ldif

How is it different from what I describe, except that I changed a few 
names so that the RDN and the AT in OC are equivalent ? (note that we 
can ename ads-partitions to partitions for clarity sake, if needed)
>> For instance, we have a LdapServer which id is "myLdapServer", then the DIT
>> will look like :
>>
>> ou=config/
>>   ads-directoryServiceId=myDS/
>>     ou=ads-servers/
>>       ads-server=myLdapServer/     -->  there will have some more entries
>>       ads-server=myLdapServer.ldif -->  the entry containing the config for
>> the myLdapServer instance
>>
>> This will be the same thing for all the components.
>>
>> Note that we deduce the DN by concatenating the AT name (ads-server) with
>> the server id (myLdapServer), so this work can be done through reflection.
>>
>> One slight issue is that we have to know if an AT is a component or a simple
>> type (String, int, long or boolean). If we store the ID, then we have three
>> options :
>> - check in the DIT to see if we have some entries having the given ID
>> (costly)
>> - define a specific AT for components (which can be inherited by the
>> composite AT), so if the AT has this specific SUP, then we know it's a
>> component. For instance, ads-server AT will have the ads-component AT as a
>> SUPERIOR and ads-component AT will have 'name' as a SUPERIOR).
>> - Add a X-COMPONENT extension in the AT definition for components.
>>
>> I think that option 2 or 3 are way easier.
>>
>> With those modifications, I think we can completely read the config using
>> reflection at a small cost and with little sweat (the biggest effort would
>> be to carefully check the existing OC and AT to avoid any problem).
>>
>> Thoughts ?
> IMHO , this is config and we need to have tight control over how we
> read and use the elements
> rather than twisting it for ease of reading, using reflection is good
> but I only apply it
> to Index and Partition config entries only cause this is the *only*
> place where a user
> can define something which is NOT part of our standard distribution
> and requires custom settings.
We have tight control over the configuratio through the structure we use 
to describe the configuration, ie the ObjectClasses and the underlying 
structure, if only we had DSR implemented. In other words, with DSR, we 
can't put partitions in any other place but under the DS they are 
associated with.

If we follow this scheme, then using reflection is just using a tool to 
read something which is already well structured. Now, in order to use 
reflection, we need to have a consistent naming scheme, that's all what 
I am proposing.
> OTOH we can make any change to this config partition structure and can
> keep in the way we want
> if we never want to directly let the user edit it by hand but only
> through a tool.

In any case, the user will be able to manipulate the config. Reflection 
is totally out of scope here, because it does not force any constraints 
on how the data are structured. It just works *if* the data are 
structured, which they have to be anyway. If if they are, then it's a no 
brainer to use reflection instead of a crippled and error prone hand 
written reader.
> But our original idea is to have this config human readable and
> requires nothing or limited knowledge of how this data internally gets
> read applied
Absolutely. But it requires a structure and naming consistency.
> think we are going in a counter intuitive direction from user pov.
I don't think so. Trust me on that, I'm not focusing on making 
reflection works, I'm much more focusing on making the whole config 
structure coherent, so coherent we can use a tool like refection to read 
it :) Tools are so damn stupid that if we can use them to actually do 
something, then I think a human being can easily understand how the data 
are structured...


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message