Reusable Filters Proposition

[Joost van Baal]

[heavily snipped]
On Tue, Jan 15, 2002 at 12:21:18PM -0500, Francis J. Lacoste wrote:
> On Tue, Jan 15, 2002 at 04:33:22PM +0100, Joost van Baal wrote:
> > 
> > You store this information:
> > 
> >  <lire:filter-spec>
> >   <lire:eq arg1="$resolver" arg2="$method"/>
> >  </lire:filter-spec>
> > 
> > in dns.cfg now ( |filter_eq method="something" ).  
> 
> Not really. The idea is to put 
> 
> <lire:filter-spec>
>   <lire:eq ...>
> </lire:filter-spec> 
> 
> in it's own XML file. (I would use a reusable-filter-spec element
> wrapper with title, description, param-spec and display-spec elements added 
> to its content.) 
> 
> And we add a filters/<superservice> directory to the <datadir> namespace. 
> (We already have reports/<superservice>, schemas/<superservice>.)
> 
> In the configuration file, '|' is used to mark that the following ID
> should setup filters for the following reports.
> 
> filter_eq was what I called "magic" filter. (More on this later).
> 
> > And, indeed, we need
> > a place to store the description of the filter.  I guess the description
> > can be constructed from the description of the variables in lire:field
> > in lire:dlf-schema.  Hmm... Does lire:field allow a description?
> 
> lire:field allows a description. (We should used to document the content
> and purpose of the fields, instead of relying on comments.)

Hmm... we have a wishlist bug here...

> > I don't really get this.  Which filters do you call 'magic' and which
> > are  not 'magic'?  Is filter_eq a magic filter?
> 
> Yes, filter_eq was a 'magic' filter. 
> 
> A 'magic' filter is a filter which isn't defined through a XML
> definition. The idea was for the configuration parser to define
> on-the-fly the filter based on the filter's pseudo-id (filter_<op>)
> where parameter name's would be field and parameter's value the thing to
> match against.
> 
> But I think we should drop the 'magic' filter concept altogether.
> 
> The only 'magic' filter, I would use is |filter_none to reset the
> filters. (i.e. don't filter for next reports).

I assume a report configuration file will still look like e.g.

     requesttype-distribution
     requests-by-period                 period=1d

     |filter_eq method="recurs'
     top-requesting-hosts               hosts_to_show=10
     top-requested-names                names_to_show=10
     requesttype-distribution

when we're not using 'magic' filters; filter_eq will point to a
fullblown static xml file.  (Hmmm.... reading the mail again, I have the
vague impression your thinking goes faster than your writing ;-P )

> > Currently, the order of the subreports in the .cfg file decides for the
> > order in the final report.  Is the actual computation done in the same
> > order?  This might lead to problems after a while...  (I fear the work
> > needed to make this more flexible, though...)
> 
> Computation is done in an entirely different order (for the parrallel
> algorithm). Reports which shares the same filters (not as specified 
> in the configuration files, but really once parameter expansions is
> completed) are computed together. In the sequential algorithm, each
> reports is computed in the same pass (filtering, computation, write).

A, ok, that's very nice.

Anyway, the idea sounds sane and useful!

Bye,

Joost

-- 
Joost van Baal              . .           http://www.logreport.org/
                           .   .
/^LogReport$/               . .               joostvb at logreport.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.logreport.org/pipermail/development/attachments/20020116/d5b8249e/attachment.bin