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: Implementing Interceptor Extendibility
Date Tue, 01 Nov 2011 14:24:52 GMT
On 11/1/11 3:01 PM, Göktürk Gezer wrote:
> Hi Emmanuel,
<snip/>
>
>
> OTOH, we allow the admin to modify the order, simply by changing the
> configuration, and it could lead to some bad bad things...
>
> We wont let admin to change order for core ones.

Right now, this is allowed, through a configuration modification...
>
>
>> What if we create an implicit order by defining which interceptor is
>> allowed before each interceptor ? For instance, this is the default order :
>>
>> 1  normalizationInterceptor
>> 2  authenticationInterceptor
>> 3  referralInterceptor
>> 4  aciAuthorizationInterceptor
>> 5  defaultAuthorizationIntercepto**r
>> 6  exceptionInterceptor
>> 7  operationalAttributeIntercepto**r
>> 8  keyDerivationInterceptor
>> 9  passwordHashingInterceptor
>> 10 schemaInterceptor
>> 11 collectiveAttributeInterceptor
>> 12 subentryInterceptor
>> 13 eventInterceptor
>> 14 triggerInterceptor
>>
>> We could obtain the same order by replacing the ads-interceptororder AT by
>> a ads-previousInterceptor :
>>
>> 1  normalizationInterceptor ( previous : null )
>> 2  authenticationInterceptor ( previous : normalizationInterceptor )
>> 3  referralInterceptor ( previous : authenticationInterceptor )
>> 4  aciAuthorizationInterceptor ( previous : referralInterceptor )
>> 5  defaultAuthorizationIntercepto**r ( previous :
>> aciAuthorizationInterceptor, referralInterceptor ) (here, the
>> aciAuthorizationInterceptor may be disabled)
>> 6  exceptionInterceptor ( previous : defaultAuthorizationIntercepto**r )
>> 7  operationalAttributeIntercepto**r ( previous : exceptionInterceptor )
>> 8  keyDerivationInterceptor ( previous : operationalAttributeIntercepto**r
>> )
>> 9  passwordHashingInterceptor ( previous : keyDerivationInterceptor )
>> 10 schemaInterceptor ( previous : passwordHashingInterceptor )
>> 11 collectiveAttributeInterceptor ( previous : schemaInterceptor )
>> 12 subentryInterceptor ( previous : collectiveAttributeInterceptor )
>> 13 eventInterceptor ( previous : subentryInterceptor )
>> 14 triggerInterceptor ( previous : eventInterceptor )
>>
>> Now, for interceptors that has no specific requirement, we can set the
>> previous AT to the previous AT it will follow.
>>
>> The key is that we must distinguished between critical inteceptors (the
>> level-1 interceptors) and others. We enforce the position only within one
>> level (ie, level-1 interceptors orders are checked, then level-2, then
>> level-3). So we can add a non critical interceptor (ie level-2 or 3) in the
>> chain between two critical interceptors, without creating any trouble in
>> the critical interceptor order : the check for level-1 interceptors' order
>> is done ignoring level-2 interceptors.
>>
>> thoughts ?
>
> At first i thought that linked buckets approach. This is easier to
> implement and it is intuitive. By this way, 3th parties can also make their
> one of custom interceptor to be dependent on the some other custom
> interceptor. So that, they can create the same ordering resolution as with
> the method i proposed.
>
> But there are some problems with that approach:
>
> * First of all we're creating an implicit dependency here. Every
> interceptor in the current codebase is not mandatory. But some other custom
> interceptor implementation may refer to those which are not core. If this
> "noncore but apacheds-made" interceptor is missing in runtime. The ordering
> is impossible. We can't even warn the user or throw exception. Because in
> OSGI, everything can come and go at anytime. When we can't find the
> ads-previousInterceptor at install time of particular interceptor, we can't
> raise an error, we have to wait for it.But if that dependency never comes,
> then we can't sort the interceptor list. Serious problem!
I see your point : the interceptors should not be responsible for their 
own position in the chain. The DS should be.
>
> * Secondly, somebody may want to write custom version of the core
> interceptors. But with using linked dependencies with names, this is
> impossible without changing the source code of the interceptors those are
> dependent on the replaced one. That will create very big weakness on our
> extendibility.

Right... Numbers are less explicit, but easier to deal with.
>
> * And i believe, possessing abstraction of level into interceptor ordering
> is good for users and custom implementors. Because that way we can say for
> example, "at level1, X service is maintained", "at level2, Y service is
> maintained." and so on... So that, they inject their custom interceptor to
> the right level of their choice without knowing the name of the interceptor
> that implemented that logic.
>
> So again, this issues are the concern of  "How much extendibility we'll
> offer?" question.

The key is to not insult the future. We are targeting a 2.0, and it's 
likely to be around for years. If we build a rigid server, we are 
shooting ourselves in the foot.

I buy the idea that we are different kind of interceptors. The core 
interceptors will be the server backbone, and we should not allow anyone 
to determinate the order in which they are set. But we should allow 
anyone to inject a new interceptor in the middle of this backbone. Those 
injected interceptors may be placed anywhere in the chain, assuming that 
it's the responsibility of the user to put it at the right place.

PS : try to 'reply list' instead of 'reply all' : I will not be added in 
the list of recipients...

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


Mime
View raw message