directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radovan Semancik <>
Subject Re: OpenLDAP schema
Date Fri, 20 Mar 2015 11:36:58 GMT
On 03/19/2015 11:36 PM, Emmanuel L├ęcharny wrote:
> What we could do is to complete the schema with the elements we know
> about, like What would be needed is the
> list of missing OIDs. Obvioulsy, that should not be the standard
> behavior, and we should also flag those added elements if we wnat to be
> able to send back the modified schema (but not those specific elements).

What about a simpler solution: just leave out the missing pieces. This 
will mean that the schema will be inconsistent and/or incomplete. But in 
this case the client application is aware of the risk of inconsistency 
because it has to set the quirks mode and the relaxed mode. So the 
client application can expect that some attributes will have syntax == 
null. I know that we can lose some information here, e.g. if syntax == 
null then the client cannot even get the syntax OID. But it still may be 
OK. E.g. in my connector it would be just fine to assume string type as 
a default for these cases. It seems that these "quirks" only apply to 
attributes that are not frequently used (read: not used at all in 
99.99999% cases). And I hate the idea of complicating the API just to 
support exotic use case.

All I need is for the schema parser not to die during parsing. It is OK 
if the parser produces inconsistent schema. I do not really care if the 
resulting schema is screwed at places that are extremely unlikely to be 
used at all. I can still detect that the schema is screwed at the client 
level. And then assume some kind of default behavior. Or throw an error 
if the schema is really bad. But the decision is on the client, not on 
the API.

And if the client wants strict consistency then it can leave the API to 
use default settings (quirks off, strict mode). Then there is still 
guarantee of schema consistency. But realistically, I have tried three 
different real-world LDAP servers and this strict mode fails to work 
will all three of them. So I think that the API really needs this 
alternative mode to be useful also outside the strict ApacheDS world.

Let me experiment with this a bit using real OpenLDAP and 389ds 
instances. I'll report the results.

Radovan Semancik
Software Architect

View raw message