[ http://issues.apache.org/jira/browse/DIREVE-52?page=all ]
Alex Karasulu updated DIREVE-52:
--------------------------------
Fix Version: 0.9.5
(was: 0.9.3)
Description:
Ok there is soooo much that can and needs to be done here. However this IBS
needs to be taken step by step. First off the initial goal for a base line is
to just check attribute value syntax compliance and entry objectClass
compliance using what we currently have as the schema subsystem.
Basically we ignore things like subschemaSubentry information which we do not
yet have modeled. We do not use the ou=system partion yet because the schema
sub subsystem has not matured to that point yet. We can use mock wrappers
around the BootstrapRegistries for accessing schema inforamtion right now as if
the schema subsystem is fully operational.
However let's talk about what can and will be some day ...
First all the goodies will be there where subschemas will be used to
selectively constrain subtrees within the DIT as administrator intend with a
high degree of granularity. This all comes out of nice stuff in X.500 which is
making its way back into LDAP thanks to that guy Kurt from OpenLDAP. Anyhow
we'll have all the usual schema suspects we can use like DitContentRules,
NameForms et. cetera. including subtree refinements to really really control
schema the way it needs to be controled.
Now we can go further obviously and have talked about how we can do this.
First off we want administrative maintenance of schema information within the
ou=system area. Using this area we store the core schema objects and their
associations in logical schema categories like the nis, java and core schemas
et. cetera. We enable the presentation and manipulation of this region by
server admins. Also we present this content in the usual manner at cn=schema
for example as one fat entry with lots of attributes using the usual syntaxes
for the schema types.
An neat thing that can be done is to use a subtree specification to describe
the entries to which certain types of schema checks can be applied. This
thought came to me when I realized that full blown schema checking is not
always needed everywhere in the DIT. In fact at times full blow schema checks
will get in the way and slow down the server. If we can find a way to specify
controls for schema checking this would be a good place to implement them.
was:
Ok there is soooo much that can and needs to be done here. However this IBS
needs to be taken step by step. First off the initial goal for a base line is
to just check attribute value syntax compliance and entry objectClass
compliance using what we currently have as the schema subsystem.
Basically we ignore things like subschemaSubentry information which we do not
yet have modeled. We do not use the ou=system partion yet because the schema
sub subsystem has not matured to that point yet. We can use mock wrappers
around the BootstrapRegistries for accessing schema inforamtion right now as if
the schema subsystem is fully operational.
However let's talk about what can and will be some day ...
First all the goodies will be there where subschemas will be used to
selectively constrain subtrees within the DIT as administrator intend with a
high degree of granularity. This all comes out of nice stuff in X.500 which is
making its way back into LDAP thanks to that guy Kurt from OpenLDAP. Anyhow
we'll have all the usual schema suspects we can use like DitContentRules,
NameForms et. cetera. including subtree refinements to really really control
schema the way it needs to be controled.
Now we can go further obviously and have talked about how we can do this.
First off we want administrative maintenance of schema information within the
ou=system area. Using this area we store the core schema objects and their
associations in logical schema categories like the nis, java and core schemas
et. cetera. We enable the presentation and manipulation of this region by
server admins. Also we present this content in the usual manner at cn=schema
for example as one fat entry with lots of attributes using the usual syntaxes
for the schema types.
An neat thing that can be done is to use a subtree specification to describe
the entries to which certain types of schema checks can be applied. This
thought came to me when I realized that full blown schema checking is not
always needed everywhere in the DIT. In fact at times full blow schema checks
will get in the way and slow down the server. If we can find a way to specify
controls for schema checking this would be a good place to implement them.
Environment:
> Create Schema Checking and Presentation IBS
> -------------------------------------------
>
> Key: DIREVE-52
> URL: http://issues.apache.org/jira/browse/DIREVE-52
> Project: Directory Server
> Type: Task
> Components: interceptors
> Reporter: Alex Karasulu
> Fix For: 0.9.5
>
> Ok there is soooo much that can and needs to be done here. However this IBS
> needs to be taken step by step. First off the initial goal for a base line
> is to just check attribute value syntax compliance and entry objectClass
> compliance using what we currently have as the schema subsystem.
> Basically we ignore things like subschemaSubentry information which we do not
> yet have modeled. We do not use the ou=system partion yet because the schema
> sub subsystem has not matured to that point yet. We can use mock wrappers
> around the BootstrapRegistries for accessing schema inforamtion right now as
> if the schema subsystem is fully operational.
> However let's talk about what can and will be some day ...
> First all the goodies will be there where subschemas will be used to
> selectively constrain subtrees within the DIT as administrator intend with a
> high degree of granularity. This all comes out of nice stuff in X.500 which
> is making its way back into LDAP thanks to that guy Kurt from OpenLDAP.
> Anyhow we'll have all the usual schema suspects we can use like
> DitContentRules, NameForms et. cetera. including subtree refinements to
> really really control schema the way it needs to be controled.
> Now we can go further obviously and have talked about how we can do this.
> First off we want administrative maintenance of schema information within the
> ou=system area. Using this area we store the core schema objects and their
> associations in logical schema categories like the nis, java and core schemas
> et. cetera. We enable the presentation and manipulation of this region by
> server admins. Also we present this content in the usual manner at cn=schema
> for example as one fat entry with lots of attributes using the usual syntaxes
> for the schema types.
> An neat thing that can be done is to use a subtree specification to describe
> the entries to which certain types of schema checks can be applied. This
> thought came to me when I realized that full blown schema checking is not
> always needed everywhere in the DIT. In fact at times full blow schema
> checks will get in the way and slow down the server. If we can find a way to
> specify controls for schema checking this would be a good place to implement
> them.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
