On 10/4/07, David Jencks <david_jencks@yahoo.com> wrote: 
On Oct 4, 2007, at 11:21 AM, Alex Karasulu wrote:

SNIP ...

If this idea of configuring lots of interceptor lists in server.xml worked out it might be pretty easy for these to be specified per partition as well.

I think we could have a combinatorial explosion if we did this.  Perhaps partitions should just
expose their "skiplist" rather than defining a chain specifically for each partition's suffix for each
operation.

The combinatorial explosion certainly seems like a real danger.   I kind of think the skip list goes with the operation better than with the partition.

The skip list can also go into the interceptor.  Interceptors may be configured with a set of distinguished names
to be skipped.  The InterceptorChain can leverage this information to automatically bypass an interceptor based
on the distinguished name of the target entry the operation is performed on.

If the functional names you talk about below (i.e. "normalization" ) can be configured in the interceptor for different
regions of the DIT then this can be controlled pretty well.  This alternative my be better at targeting specific functionality. 
For example Matt will want to just skip one or two interceptors at most for his partition.  Configuring this as an exception
on the interceptor may be best.  Don't know tho.

BTW there are major concerns with bypassing interceptors where bypassing one interceptor may cause another to
fail. This nasty coupling is what I want to get rid of but don't know how exactly.

Thinking about how the skip lists work now I recall that they aren't based on interceptor identity but name although in trunk the name is by default the class name of the interceptor.  lets see if I can explain this so anyone can understand what I'm thinking.... if the skip lists work by functional name and the partitions supply the skip lists with the interceptors named functionally then the skip lists would work with different interceptor chains even though the implementation of some functions would be with different classes.

e.g. the normalization would be done by a different interceptor in the normal and the Matt partitions, but they'd have the same name... so if a skip list included "Normalization" that interceptor, whatever it happened to be for the target partition, would get skipped.

Yes we should use symbolic/functional names you suggest instead of the interceptor class name.

I'll try to explain again from a different point of view...

- partitions specify a "complete" interceptor stack for themselves.  The interceptors have functional names that reflect what they do rather than necessarily their class.

The "complete" part sounds like it might lead to greater verbosity and might also cause other severe problems
where we cannot have two instances of the same interceptor in the same DirectoryService.  Perhaps we can use
reuse but still there will be one offs and issues if we do do that.

- skip lists are based on these functional names

+1

- there's something before we get into the interceptor stack that picks the right interceptor stack based on the target partition

This can be done but there are just some functions (interceptors) that must be handled or else critical services fail.

- the skip lists now work for any interceptor stack because they say what functionality to skip.

What I don't know is if (3), the thing that picks the correct interceptor stack, is possible to write.

Yeah I worry sometimes.  You've got some great ideas and I'm learning a lot from you.  I'm very appreciative
regarding that.  However you have not been bit by this mechanism as much as we have.  It's made us suffer
a lot :).  It really takes getting shocked a few times to have the pavlovian response which people like myself and
Emmanuel have when dealing with these interceptors and the chain mechanism.  All the pain comes rushing back into
our heads when we consider our options.  I'm learning a lot from your keen insight and design ideas but I hope you
have some of our challenges cached in mind when considering some of these options.  It will just make us more
efficient while discussing these things.  I know we cannot instantly give you the background knowledge but you're
still very insightful all the same. Perhaps in time you'll begin to see the nasty issues we have but that kind of takes
looking at how we implement protocol specific features a bit: I don't know if this something you want to delve into
since it's a bottomless pit.  To a degree tho you can piggy back on our experiences.  Anyways ...

Perhaps we can discuss other patterns in addition to seeing what could be done to make the present more one
capable of satisfying our needs.  I think we're onto some good ideas tho.  We just need to think about the pros and
cons.

Alex