On Mon, Oct 18, 2010 at 3:03 PM, Emmanuel Lecharny <firstname.lastname@example.org>
I'm a little annoyed atm trying to get the schema element extensions handled by the server. Let me explain what is my problem :
- all the schema elements (AT, OC, MR, S, ...) can have some extensions, as explicited by RFC 4512.
- a schema element may have more than one element
- an extension has a key and at least one value (but may have many)
- we store the schema elements as LDIF
- we also allow the server to parse those schema elements when provided as specified by the RFC
- when parsing them, the extensions are correctly stored into the corresponding Java instances, as manipulated by the schemaManager
So the problem is how do we express those extensions in a LDIF format? Currently, we don't...
Let me give you some example. The following OC (using the RFC syntax) is correctly parsed :
objectclass ( 126.96.36.199 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) X-extension 'test' X-otherExtension ( 'test1' 'test2' ) )
The 2 extensions are stored into Map<String, List<String>> into the corresponding instance of ObjectClass.java.
The corresponding LDIF file for this instance would be :
m-description: RFC2256: a person
but I have no idea on how to express the extensions...
Should it be something like :
m-extension: X-extension 'test'
m-extension: X-otherExtension ( 'test1' 'test2' )
if so, that means we will have to parse those extensions when reading them. Not convenient.
Another proposal would be to use AT's options :
I like this approach.
which is probably better, but as we don't currently support AT's option, this is not possible.
So, what about starting to think about how to handle AT's options right now, assuming it's a part of the spec, that we need it to handle languages, and it's also mandatory for binary attributes (certificate;bianry, for instance) ?