Now that I have written some test cases for the filters in the varia directory, I feel I have a much better understanding of them. So, now I understand some of the comments about the filter extensions I previously submitted for submission. They were a bit overkill in their design and did pretty much the same thing.
But I still think there are some useful changes that can be made in this area. 1) If the get/setAcceptOnMatch methods and a decide() method that uses the set values are moved to an abstract base class, then that base class could be used by any developer to develop their own filters that are easy to plug into this filter chain. LevelRangeFilter and LevelMatchFilter would be changed to descend from this base class and there would be no affect/change to their current api. 2) Implement more filters using the abstract base class: NDCMatchFilter, MDCMatchFilter, LoggerMatchFilter, etc. Again, they would be easily compatible with the other filters of this type, using the same get/setAcceptOnMatch methods in the base class. 3) I would like to add my SetLocationInfoFilter to the set as well. It would not use the base class since it is just a pass-thru type filter. 4) Test cases for all of the above. If folks agree, I will get started in this shortly. After this I would like to start exploring the watchdog/reconfiguration area. -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
