directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Boorshtein" <>
Subject Re: [ApacheDS] Cost of interceptors
Date Tue, 29 May 2007 06:53:34 GMT

I've been reading this discussion and as MyVD uses a very similar
model I thought I'd throw in my 2 cents....

> - as each method in an interceptor should know which is the next
> interceptor to call for the same method, this leads to some mi of
> concept : we are dealing with a chain of global interceptors into which
> each motho has its own path. At this point I just wonder if it would not
> be better to define a add() interceptorChain, delete() interceptorChain,
> search() interceptorChain etc.

This is exactly how MyVD works.  There is a Chain mechanism with a
different chain implementation for each operation.  While this did
lead to some minor code duplication I'm sure I could engineer that
out.  The tradeoff however is a much simpler model for the inserts (or
in apacheds' case interceptors).

> - I'm not sure that a method should know which interceptor it must call.
> I think it would be better to see this interceptor chain as a state
> machine, with calculated transitions. Adopting this vision will allow a
> lighter system, where pre and post conditions would be run partly on the
> engine (the transition selector) and partly in the next state. In fact,
> we will have two kinds of pre and post conditions : selectors pre/post
> productions, and applicatives pre/post treatment.

Again, this is exactly how MyVD's insert chain works.  In point of
fact an insert has absolutely no idea what the next point in the chain
is (at least by default).  This makes it easier to implement inserts
as it allows for the creation of more generalized inserts.  For
instance MyVD has both global inserts (which are executed before the
router) and local inserts (configured for individual namespaces).  A
single insert can run in either context because the chain is the state

> Ok, I want to be honest, I'm not sure I see a better solution than the
> one we actually have, which works pretty well, but I *feel* that it
> could be done better. May be I'm totally wrong, may be is just because
> I'm an old fart and pretty much biased toward state machines - old
> school computer science :) -, I don't know. I just wanted to open a
> thread on this subject, but, please, *no flame* ! I don't think there is
> an ultimate solution, I would just like to see if we have explored other
> paths...

Well, I don't know if "better" is the correct word but it has
certainly worked well thus far.  You still have the debugging issues
(I tend to make liberal use of a dump transactions plugin rather then
debugging for the reasons cited in the above thread).

OK, maybe 10 cents worth of info....


View raw message