directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From directory-...@incubator.apache.org
Subject [jira] Created: (DIREVE-52) Create Schema Checking and Presentation IBS
Date Sat, 23 Oct 2004 19:34:25 GMT
Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/DIREVE-52

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: DIREVE-52
    Summary: Create Schema Checking and Presentation IBS
       Type: Task

     Status: Open
   Priority: Major

    Project: Directory Eve
 Components: 
             interceptors

   Assignee: Alex Karasulu
   Reporter: Alex Karasulu

    Created: Sat, 23 Oct 2004 12:34 PM
    Updated: Sat, 23 Oct 2004 12:34 PM

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. 


---------------------------------------------------------------------
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message