directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: New module for the ACI parser needed
Date Wed, 30 Jun 2010 11:02:24 GMT
  On 6/30/10 11:36 AM, Alex Karasulu wrote:
> On Tue, Jun 29, 2010 at 6:09 PM, Emmanuel Lecharny<>wrote:
>>   Hi guys,
>> while working on the ACI parser, I hit a wall : if we want the parsed ACI
>> to be used directly in the server without having to convert EntryAttributes
>> to JNDI Attribute, we have to make the ACI parser schema aware. As it's a
>> good idea to do so, I checked if it was possible.
>> Sadly, the ACI parser is part of the shared-ldap module, when the
>> SchemaManager is in a separate module, depending on shared-ldap.
>> In order to solve this issue, I see no better way than creating a new
>> module (shared-aci), any other solution would be a real PITA (like
>> post-processing the ACI once parsed to inject the schemaManager into the
>> elements).
>> I will try to create this new module, and will give you some feedback.
>> Please feel free to comment.
> Perhaps there's some functionality in the SchemaManager that can be
> separated out into another class to be put into the shared area. Or as
> another option the SchemaManager functionality for dealing with schema
> lookups can be separated and put into shared.
> Basically my thinking is as follows:
>    o the parser just needs to be schema aware
That's done now. We had some discussion about AT that does not belongs 
to the SchemaManager when parsing an ACI (like some AT found in an entry 
which has an ExtensibleObject OC, but that does not make any sense to 
protect such external ATs).

>    o being schema aware (read-only) can be achieved either with
> non-SchemaManager components or a new SchemaManager implementation
Well, I think the current SchemaManager is already good enough for that 
purpose. I don't really see the added value to create a new one.
> If the SchemaManager interface has write based methods the interface can be
> broken down into two separate interfaces to compose the SchemaManager
> interface. Then the read only component of this contract can be placed and
> implemented within shared.
Not sure I see where you are going to.
> The read only component need not interact with the DS since nothing needs to
> be changed in the registries. It's there for lookups. The code there can
> then be reused elsewhere like in the server.
> This just shows us that the SchemaManager interface needs to be further
> decomposed. Whether this warrants another shared module (shared-aci) perhaps
> is up for debate.
I'm not sure we want to separate the read/write interfaces for the 
Schema. There is no need to do so atm, I don't see the added value. Also 
it won't solve the problem I have.

Emmanuel L├ęcharny

View raw message