On Mon, Oct 18, 2010 at 3: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 > > 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) ? > > > +1 -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
