I remember such question is usually responded with
"your question is not specific to openldap. It is out-of-topic, go ask ldap@umich.edu instead"
but I waited a night and no one responds. Either people are more tolerant these days, or that openldap became so unimportant that no one bother to cleanse the mailing list;)
On Mon, 5 Aug 2013, Bennett, Steve wrote:
I'm trying to store some attributes with a bit more structure than simple key:value pairs.
I think it is much needed. I have a lot of different needs of rich-data attribute values. Examples:
# These need special ordering rule so that you can pick out the product that # is large enough.
myResolution: 1024x768 myFormatSize: 21mmx23mm myDisplayArea: 15inx20in
# These too, need special ordering rule, so that you get the equipment that # fits your shelf:
myDimension: 21x23x23 myStorageCapacity: 50x38x23 myShipmentContainDimension: 100x320x310
# This one is a key-value structure, it requires a numeric qualifier: # it means this person won 3 Silver Medals and 4 Gold Medals
myAwards: dn=Silver Medal,ou=awards,dc=my,dc=co $ 3 myAwards: dn=Gold Medal,ou=awards,dc=my,dc=co $ 4
All these requires some overlay, and, it looks very much like IO-logic, thus feasiable to overlay the ldap server instead of overlaying the appliation business logic.
There seems to be a bit of a precedent in the Cosine otherMailbox attribute, but I don't really understand what's going on
Following this lead, I looked up the attribute, and is much surprised, that it has its own syntax. The SYNTAX 'otherMailBox' seems to be created for just one attribute to use. I would have designed the SYNTAX to be 'labeledMailbox', and leave the meaning of the label to be defined by attributeType.
I feel that otherMailBox designer extends LDAP only to solve his / her problem with least system change. Perhaps when you do make your module, you can design it general-purpose, and share it with others? Or maybe we can work it out together :)