directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <directory-...@incubator.apache.org>
Subject [jira] Updated: (DIREVE-52) Create Schema Checking and Presentation IBS
Date Wed, 24 Aug 2005 16:58:12 GMT
     [ http://issues.apache.org/jira/browse/DIREVE-52?page=all ]

Alex Karasulu updated DIREVE-52:
--------------------------------

    Fix Version: 0.9.3
      Assign To:     (was: Alex Karasulu)

> 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.3

>
> 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


Mime
View raw message