directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject About Attributes, OID, and names...
Date Sun, 22 Apr 2007 10:21:00 GMT
Hi,

we have had a little convo yesturday with Alex about the way 
attributeTypes are handled.

AT = AttributeType
AV = AttributeValue


First let's sum up some of the problems we have :
- when looking for an AT in an attributes, we are using the get( String 
) method. The problem is that the String could be a name, an alias or an 
OID. Lookup like attrs.get( "entryACI" ) just returns a value *if* the 
"entryACI" exists as an attribute. If the user has created an attribute 
with AT = "2.5.24.5" (entryACI OID), the the get() method will return 
nothing.
- we may also have aliases (commonName instead of cn), so we must search 
for all the possible values of an AT (2.5.4.3, cn or commonName)
- the user may provide a name or an alias with his own casing : CN or 
Cn, CommonName or commonName...)
- we must return the AT as it has been injected by the user : if a user 
create an entry with CN=something, we should return CN=something later 
when this user request the server for this AT. In other words, we should 
not return commonName=something unless specifically requested by the 
user (one can do a search request asking for cn, CN, commonName or even 
2.5.4.3, and we should return the response using the user syntax)
- last, not least, this should be as fast as possible (just because some 
retarded hackers seems to be looking over our shoulder ;)

Ok, some proposals now:
1) Attributes should be normalized as soon as spossible, to let the 
server manipulate OIDs instead of multiple names
2) We should *never* use any AT names into the server (such as 
attrs.get( "entryACI" ) or attrs.get( "2.5.24.5" )), but constants like 
: attrs.get( SchemaConstants.PRESCRIPTIVE_ACI_AT_OID )
3) Of course this imply that we declare all those constants (work in 
progress)
4) the internal structure of AttributesImpl is questionnable : for each 
attribute, we should keep the UP AT and the values, plus the associated 
OID (this is a triplet). As we only receive the two last elements, we 
must add the first part (OID). To speedup lookups, the idea is to store 
those triplets into a hashMap. The big problem is that we have no way to 
get this OID inside AttributesImpl, because this class has been designed 
to be used bu the client side, so we must find a way to feed the map 
without changing the API

Considering the last point, the best approch seems to define a 
ServerAttributesImpl, for internal use only. The little tricky problem 
with this approach is that it's not really optimal : attributes are 
constructed during the decoding phase, where we don't have access to the 
registries (the place where AT <-> OID mapping is stored). And this 
codec is stored in shared-ldap...

We might go a step further, with a shared-ldap-server and a 
shared-ldap-client, but this is a major refactoring...

Another possibility is to copy the entire Attributes during the 
Normalization phase, substituting names for OIDs. But this means 
creating a new Attributes. Costly ...

ideas ?


Mime
View raw message