Hi Emmanuel, On Mon, Oct 18, 2010 at 2:03 PM, Emmanuel Lecharny <[email protected]> wrote: > Hi guys, > > 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 ( 2.5.6.6 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 : > version: 1 > version: 1 > dn: m-oid=2.5.6.6,ou=objectClasses,cn=core,ou=schema > objectclass: metaObjectClass > objectclass: metaTop > objectclass: top > m-name: person > m-oid: 2.5.6.6 > m-description: RFC2256: a person > m-supobjectclass: top > m-typeobjectclass: STRUCTURAL > m-must: cn > m-must: sn > m-may: userPassword > m-may: telephoneNumber > m-may: seeAlso > m-may: description > > 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 : > m-extension;X-extension: test > m-extension;X-otherExtension: test1 > m-extension;X-otherExtension: test2 > > which is probably better, but as we don't currently support AT's option, > this is not possible.
I'd vote for that proposal, it is a good way to persist a Map<String, Collection<String>>. > 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) > ? +1 A third solution would be to store each extension into its own subordinate entry. This is a more generic approach to persist a Map, but probably oversized for this case. dn: m-oid=2.5.6.6,ou=objectClasses,cn=core,ou=schema dn: m-name=X-extension,m-oid=2.5.6.6,ou=objectClasses,cn=core,ou=schema objectclass: metaExtension objectclass: metaTop objectclass: top m-name: X-extension m-value: test dn: m-name=X-otherExtension,m-oid=2.5.6.6,ou=objectClasses,cn=core,ou=schema objectclass: metaExtension objectclass: metaTop objectclass: top m-name: X-otherExtension m-value: test1 m-value: test2 OC metaExtension and AT m-value are just proposals and don't exist yet. Kind Regards, Stefan
