directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: OpenLDAP schema
Date Fri, 20 Mar 2015 13:19:00 GMT
Le 20/03/15 12:36, Radovan Semancik a écrit :
> 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.

We *can* do that, but that will most certainly reqire some refactoring
of the API, as we heavily depend on the syntax to be present. By working
with an inconsistant schema, you can expect many NPE here and thre.

That's fine, we can fix that...
>
> All I need is for the schema parser not to die during parsing. 

I do,'t think it will die. We can conduct some experiment with a twisted
schema to check that.

> 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.

Anyway, we have anticipated teh fact that some schema might be wrong,
and the schema is parsed in 2 steps : the first one just read
everything, doing no control, the second phase checks everything, and
return the errors we have seen. In any case, we *have* a schemaManager
which is fully loaded (the logic was changed on purpose for teh Studio
Schema plugin to be able to work whatever schema you were processing).
>
> And if the client wants strict consistency then it can leave the API
> to use default settings (quirks off, strict mode).

+1
> 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. 
Well, ApacheDS is quite unique there ;-)

> So I think that the API really needs this alternative mode to be
> useful also outside the strict ApacheDS world.

Agreed. I think we have all teh logic ready, we may just to have to tune
a bit the things with real life schema.

What could heelp here is that you psuh a schema you know is having pb,
so that we can run a quick test on it.
>
>
> Let me experiment with this a bit using real OpenLDAP and 389ds
> instances. I'll report the results.

Great !



Mime
View raw message