directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@apache.org>
Subject Re: Some more thoughts about AP handling
Date Sat, 15 Jan 2011 13:44:37 GMT
On 1/15/11 1:59 PM, Alex Karasulu wrote:
> On Sat, Jan 15, 2011 at 1:01 PM, Emmanuel Lecharny<elecharny@gmail.com>  wrote:
>> Hi guys,
>>
>> I'd like to share some thoughts I have had yesterday and this morning while
>> I was lying in my bed (one of the best place to find solutions to problems
>> with the shower).
>>
>> AP support suppose you deal with some constraints, as explicited in various
>> RFCs :
>> - we must support SAP and IAP, otherwise it's too complicated to manage ACIs
>> when they are overlapping rights
>> - Subentries must be referenced in selected entries as a DN
>> - we must cover at least 3 administrative role : ACI, Collective-Attributes,
>> Subschema, two of those aspects being described in RFCs
>> - every operation must be atomic, ie either execute *fully* or be aborted
>> *fully*. We can't have a partial execution.
>>
>> In order to correctly implement APs, we don't have many possible solutions.
>> Let me list them again :
>> #0 don't support AP at all. Well, it's not really an option :)
>> #1 evaluate entries on the fly when we access them, all the time
>> #2 evaluate entries on the fly the first time we access them, and store the
>> result
>> #3 evaluate entries when the AP is modified, and persist the state
>>
>> All the 3 last approaches have pros and cons. I have ruled out option #0, so
>> let's analyze the three others
>>
>> #1 pros :
>> - atomicity is easy to enforce : we always do one single modification when
>> managing APs
>> - it's easy to implement, as we just have to handle subentries in the search
>> and lookup methods
>> - we don't have any operation that could impact the whole set of entries
> Also must ask, when search touches entries and updates them in this
> lazy update mechanism, do we replicate the changes or these are
> changes that never get replicated? I would think the later.

This is #2. In #1, the entries are not modified at all on disk.
>> #1 cons :
>> - we will have to pay the price of the entry evaluation for every single
>> read we do on any entry
> Every single first read correct?
correct.
<snip/>
>> , no matter what, before we can implement either #2 or
>> #3. And once we get this feature added in the server, then I do think that
>> #3 is the best possible option.
> Yes yes yes ! I totally agree.
>
> Some things really cannot progress unless some supporting
> infrastructure is laid down. The AP subsystem is exactly suffering
> from this. Everything must evolve together. Otherwise we wind up
> implementing a lot of forced solutions that are less than optimal with
> hacks, work arounds and one offs. Things get more complex and brittle
> causing more pain down the line.
>
> Let's switch into a mode of cleaning up the shop after all this heavy
> sawing and hammering. Sit down and plan a micro strategy with a clear
> mind and clean shop. Then knock this out in a solid and easy way.
>
> The AP thing was getting way too hard. I commend you on your effort,
> and you're close but it's almost impossible to do without a local
> transaction manager. Definitely impossible to do RIGHT without one.

The main issue here is that I was trying to catch many birds with one 
stone. Not wanting to implement a transaction manager made #2 solution 
the only one available, but it's not a perfect one.

Right now, I really think we should go step by step, following the 
following path (roughly) :
- first make the current trunk working. We have an issue as the 
subentries are not read back when the server is stopped, so we can't 
have the ACI working again. That's a stupid error which can be fixed easily.
- implement #1 : no more modifications made on the backend, all is 
evaluated on the fly
- have a TransactionManager (TM) implemented
- add support for IAPs
- once all those pieces have been added, then we can move to #3

Of course, we have other things on our plate which can be done in 
parallel, like refactoring the APIs.

That just some options we can discuss atm. Let's use this week-end 
discussing, and start back with a better roadmap later next week.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


Mime
View raw message