Mydor
06-22-2002, 11:21 AM
After looking at the filters by BlueAdept I thought there had to be a better way to manage "global" filters instead of including them in each and every zone filter file.
My first thought is to have SEQ load the filters.conf file after it loads a more specific zone filter file. I've managed a cludge in the filter.cpp that works, but I'm not happy with it. Ideally I think it should go in the filtermgr.cpp, but I am not fluent enough in c++ to follow how the two interact yet. The additional problem came from the fact that loadFilters flushes the stored filters before opening the file, so I limited loadFilters to that task as well as figuring out what the global filename should be and passing the actual reading and parsing of the filter file to a new method.
My second thought, that I haven't worked on yet but would be more suited for a location in filter.cpp, is to have some type of include directive in the filter file. I think I like this idea better as it allows for more flexibility. However, since # is used for comments I'm not sure the best way to denote the directive would be. One thought, which I think is a little ugly would be [include /pathto/somefilter.conf]. Similar to the first idea, would have to split out the actual reading/parsing of the filter file to a new method so the includes don't get wiped out by the clear, but overall I think a better solution to the whole problem.
I would like some input on the two ideas and I will work on putting it together and getting a patch for it. Of particular interest to me would be comments on the second solution and how to denote the include directive since that is the course I would rather take. The only other thing that would be missing is to know LOGDIR inside of filter.cpp. How much havoc would it cause to #include "main.h" in filter.cpp?
My first thought is to have SEQ load the filters.conf file after it loads a more specific zone filter file. I've managed a cludge in the filter.cpp that works, but I'm not happy with it. Ideally I think it should go in the filtermgr.cpp, but I am not fluent enough in c++ to follow how the two interact yet. The additional problem came from the fact that loadFilters flushes the stored filters before opening the file, so I limited loadFilters to that task as well as figuring out what the global filename should be and passing the actual reading and parsing of the filter file to a new method.
My second thought, that I haven't worked on yet but would be more suited for a location in filter.cpp, is to have some type of include directive in the filter file. I think I like this idea better as it allows for more flexibility. However, since # is used for comments I'm not sure the best way to denote the directive would be. One thought, which I think is a little ugly would be [include /pathto/somefilter.conf]. Similar to the first idea, would have to split out the actual reading/parsing of the filter file to a new method so the includes don't get wiped out by the clear, but overall I think a better solution to the whole problem.
I would like some input on the two ideas and I will work on putting it together and getting a patch for it. Of particular interest to me would be comments on the second solution and how to denote the include directive since that is the course I would rather take. The only other thing that would be missing is to know LOGDIR inside of filter.cpp. How much havoc would it cause to #include "main.h" in filter.cpp?