You are viewing a plain text version of this content. The canonical link for it is here.
Posted to api@directory.apache.org by Kiran Ayyagari <ay...@gmail.com> on 2010/02/03 12:51:44 UTC

making client schema aware

hi guys,

    To make the client aware of schema we need to load it in one of the two ways
    mentioned below

     1. load the schema from the server if the server exposes it
     2. have a common set of schema elements bundled with client

    Do you see any other ways to make the client schema aware?
    What schemas should be loaded by default?

Kiran Ayyagari

Re: making client schema aware

Posted by Matthew Swift <Ma...@Sun.COM>.

On 03/02/10 13:30, Emmanuel LŽcharny wrote:
> [...]
>> - The schema can be loaded/extended from LDIF file
> Do you have the format you are using ?
>

The format of our schema files is pretty straightforward: just plain old 
LDIF. For example:

dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
attributeTypes: ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch
   SUBSTR caseIgnoreSubstringsMatch SYNTAX 
1.3.6.1.4.1.1466.115.121.1.15{32768}
   X-ORIGIN 'RFC 4519' )
attributeTypes: ( 2.5.4.49 NAME 'distinguishedName'
   EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
   X-ORIGIN 'RFC 4519' )
   ...

So it is possible to import OpenDS schema using an LDIF reader. Via this 
mechanism we support loading of all schema elements with the exception 
of those that require implementation code. Specifically, matching rules 
are not loaded this way nor are most* syntaxes - instead these are 
defined in the server configuration together with a reference to the 
Java class implementing rule/syntax functionality. We then expose the 
schema to clients via a single cn=schema entry which includes all the 
loaded schema elements as well as virtual attributes for the syntaxes 
and matching rules.


Matt
* it is possible to define new syntaxes via the schema using the schema 
extensions (meta-syntaxes) that Ludo presented at LDAPcon
https://www.opends.org/wiki/page/SubstitutionSyntax
https://www.opends.org/wiki/page/EnumerationSyntax
https://www.opends.org/wiki/page/RegexSyntax
http://blogs.sun.com/Ludo/entry/regular_expression_based_attributes_in
http://blogs.sun.com/Ludo/entry/enumeration_based_attributes_in_ldap


Re: making client schema aware

Posted by Emmanuel LŽcharny <el...@gmail.com>.
Ludovic Poitou a écrit :
> Hi Kiran,
>
> In OpenDS SDK, we have 3 ways for making schema aware clients.
>
> - There is a default core schema defined in the SDK. This includes standard LDAP syntaxes, matchingrules, attributetypes and objectclasses (rfc4512) + rfc3045, rfc3112, rfc4519, rfc4530 + very few Sun specific like an approximatematchingrule and password related syntax/MR.
>   
Ca we put on the wiki all the AT, OC, S and MR we are using, with a 
description of the OpenDS specific ones ?

I will create a page where I will push all the basic schema we use and 
OpenLDAP uses for that purpose.
> - The schema can be loaded/extended from LDIF file
>   
Do you have the format you are using ?


Re: making client schema aware

Posted by Ludovic Poitou <Lu...@Sun.COM>.
Hi Kiran,

In OpenDS SDK, we have 3 ways for making schema aware clients.

- There is a default core schema defined in the SDK. This includes standard LDAP syntaxes, matchingrules, attributetypes and objectclasses (rfc4512) + rfc3045, rfc3112, rfc4519, rfc4530 + very few Sun specific like an approximatematchingrule and password related syntax/MR.


- The schema can be loaded/extended from LDIF file

- The schema can be loaded from a server.

Ludo


On Feb 3, 2010, at 12:51 PM, Kiran Ayyagari wrote:

> hi guys,
> 
>   To make the client aware of schema we need to load it in one of the two ways
>   mentioned below
> 
>    1. load the schema from the server if the server exposes it
>    2. have a common set of schema elements bundled with client
> 
>   Do you see any other ways to make the client schema aware?
>   What schemas should be loaded by default?
> 
> Kiran Ayyagari

---
Ludovic Poitou                                    Sun Microsystems Inc.
OpenDS Community Manager            Directory Services          
http://blogs.sun.com/Ludo/         Grenoble Engineering Center - France

Join OpenDS, https://opends.dev.java.net/servlets/ProjectMembershipRequest

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~









Re: making client schema aware

Posted by Emmanuel LŽcharny <el...@gmail.com>.
Kiran Ayyagari a écrit :
> hi guys,
>
>    To make the client aware of schema we need to load it in one of the 
> two ways
>    mentioned below
>
>     1. load the schema from the server if the server exposes it
>     2. have a common set of schema elements bundled with client
>
>    Do you see any other ways to make the client schema aware?
>    What schemas should be loaded by default?
some thoughts :
- we have discussed this extensively in Portland last year with Ludovic, 
and we aggreed that the API must be schema aware
- we must provide a common set of schema (probably core, cosine, system 
and inetorgperson is the absolute minimum subset)
- it should be possible for the user to request that the schema is 
loaded from the server
- it should be possible to create a connection with a reference to the 
loaded schema
- I don't think it's a good idea to request the server for the schema 
when creating a connection. Either teh schema already exists, or no. If 
not we use the default schema.
- the user should be allowed to extend the schema with his own schema 
elements
- I suggest that the format for such schema extensio to be the OpenLDAP 
schema format, as it's concise enough


>
> Kiran Ayyagari
>