On 10/4/07, David Jencks <[EMAIL PROTECTED]> 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
