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 1.3.6.1.4.1.1466.115.121.1.3. 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 evolveum.com
