On Fri, Sep 4, 2009 at 2:19 AM, Emmanuel Lecharny <firstname.lastname@example.org>
A few thoughts :
Alex Karasulu wrote:
To clarify the bootstrapping process that we're envisoning for ApacheDS,
I've written up the following page in the wiki . Use the link above
instead since it's not going to hit confluence and shows the fast exported
page. Take a look an provide your feedback here. We can later adapt this
page to include your comments and recommendations. So let's kick this off
with some thoughts?
1) why do we need to have /schema/schema/... hierarchy, instead of having one single /schema ?
Good question. This repository of schema information encoded in LDIF models the layout of the schema partition's DIT namespace. The ou=schema context is the second 'schema' directory which has a schema.ldif file right next to it. The reason we have to put the LDIF file next the directory is due to the fact that the directory contains the children but requires an LDIF file to contain the attributes for the node. Together the LDIF file and the folder represent entries with children. In some places you won't see a directory like for example in a schema that does not have any nameForms (no schema at this point does). So all you see is the nameForms.ldif for the nameForms container but since there are no children to contain the directory is not present.
The first topmost schema folder is simply the partition container if the partition is the LDIF partition. The schema partition's id = schema like the system partition's id = system. And as you probably know, ApacheDS uses the ID of the partition to create and name the directory where the partition resides on disk, whatever the format of it's storage. So when you unpack this jar into the partitions directory of the instance, it unravels it in a top most schema directory that will contain this schema.ldif file and the schema directory.
2) I don't get the chicken and egg problem you describe and why we need a special wrapped partition
to read the four initial schema : they are just read and injected into the registries, without
any check, that's pretty much it. I do'nt see how it's different from any other schema loading,
to me all the schemas are loaded in one unique phase. probably some semantic sugar at this point ...
No semantic sugar, not sure I understand what this means either so maybe I cannot say no either at this point. But let me explain what I can about the chicken and egg problem. We need schema to enable a partition containing schema. This is the crux of the problem.
We get around this problem by loading the 4 bootstrap schema from the jar file rather than the schema partition which contains all the schema. We use two different loaders in the different schema loading phases. The first bootstrap phase uses a JarLdifSchemaLoader and the second full schema load phase uses the PartitionSchemaLoader. So there is a distinct difference in how we load although to the Registries getting loaded this feels the same.
3) Not sure I get the point about the LDAP Nirvana yet. The wiring part is a bit obscure.
Some schema can help, I will try to add them tomorrow.
OK if you ask more specific questions I can probably answer but I'm a bit spent right now to try to revamp this section. You're probably right about it being obscure. Might take a look at it again and see if I can fill it in with more details.
Thanks for the page !