Hey Andrea,

Good to hear from you after AC.  More inline ...

On Sat, Mar 28, 2009 at 11:02 PM, Andrea Gariboldi <andrea.gariboldi@gmail.com> wrote:
Just wondering if is possible to start the server without any specific configuration: no system partition, no schema, no business partition,
only have a (schema less/free) ou=config with the possible configuration options in it, "subscribed" by all modules needing some kind of configuration (by implementing a Configurable interface).

This is an interesting thought - I like the fact that you're thinking about this basis case. 

We do need some basic schema elements no matter what to support matching and searching of things like ou, objectClass etc.  Even write operations need schema to function properly.  So we need some schema data in this config partition you proposed.

BTW the system area contains very little that is of use (just the admin user) so we can combine easily combine it into this minimal ou=config area (I presume this is a basic partition?).  If we combine this with the schema and the configuration then we get:

All this can be pulled out of an LDIF file.  Then adding partitions and other things to the server can be considered extras.

For example you can have:

dn: ou=config
objectclass: top
objectclass: organizationalUnit
ou: config

dn: ou=partitions,ou=config
objectclass: top
objectclass: organizationalUnit
ou: partitions

dn: partitionId=system,ou=partitions,ou=config
objectclass: top
objectclass: apachedsPartition
partitionId: system
partitionDn: ou=system
description: you can specify an implClass attribute in this entry to configure the partition type

dn: partitionId=schema,ou=partitions,ou=config
objectclass: top
objectclass: apachedsPartition
partitionId: schema
partitionDn: ou=schema
description: you can specify an implClass attribute in this entry to configure the partition type

Once you do an ldapmodify, lets say:

dn: partitionId=system,ou=partitions,ou=config
changetype: modify
add: implClass
implClass: org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition

the JdbmPartition could implement a Configurable interface and tell the core (that is listening on the ou=config tree for Configurable interfaces)
it need a configuration branch beside its entry (partitionId=system,ou=partitions,ou=config), lets say:

dn: ou=jdbmIndexes,partitionId=system,ou=partitions,ou=config
objectclass: top
objectclass: organizationalUnit
ou: jdbmIndexes
description: you can add jdbmIndex entries under this entry to configure indexes

so that you can add an index, ldapadd:

dn: attributeId=uid,ou=jdbmIndexes,partitionId=system,ou=partitions,ou=config
objectclass: top
objectclass: jdbmIndex
attributeId: uid
cacheSize: 1000

I see what you're doing here.  You're saying do everything except the most basic configuration via the LDAP interface after starting up.  I like that because then that removes the need to have to deal with how the components are manually wired when they are.  I need to think more about this idea (I like it tho).


etc etc...

The interface could look like this:

public interface Configurable
     public EntryFilteringCursor getConfigOptions(ConfigContext ctx) throws Exception;

Does this make sense?

Yes this does make sense.  I want to think on this a bit more.  It's a bit unorthodox but it solves my problem.  Will ping you later on this.

Thanks again,


2009/3/28, Alex Karasulu <akarasulu@apache.org>:
Just one more comment.  At this point the best solution I can think of is querying each component in the wired hierarchy for all it's configurable settings to build the required LDIF entries and depositing them into an LDIF file.  This is less than optimal I think but I don't see very many options.

On Sat, Mar 28, 2009 at 7:21 PM, Alex Karasulu <akarasulu@apache.org> wrote:
Hi all,

During ApacheCon Stephan Zoerner pointed out something very interesting about an ldif based configuration. Initially we had thought the hardest problem was to figure out how to synchronize changes made to the ldif files with changes being made to the same data through the LDAP protocol.  I think we can handle this easily however this point Stephan made has left me a little perplexed.

Stephan pointed out the fact that we have both standalone configuration driven by some kind of configuration file and manual programatic wiring of the server in embedded scenarios which often will not have the ldif configuration file.  In the case with manual configuration some kind of ldif representation would need to be generated to reflect the wiring.  I have no idea how this can be achived gracefully.  I was putthing this out there to solicit others for some advice on this matter.

Any suggestions are welcome.