report configs

[Francis J. Lacoste]

[modified resend by wsl]

On dim, 2003-06-08 at 09:33, Wessel Dankers wrote:
> On 2003-06-07 23:45:28+0200, Wessel Dankers wrote:
> 
>     <param name="report"> <!-- list -->
>       <param name="header">Summary</param>
>       <param name="requests-summary"/>
>       <param name="requests-summary-by-method"/>
>       <param name="header">All Requests</param>
>       <param name="top-requesting-hosts"> <!-- dictionary -->
>         <param name="hosts_to_show">10</param>
>       </param>
>       <param name="top-requested-names">
>         <param name="names_to_show">10</param>
>       </param>
> 
> <!-- You may want to uncomment those if you run a
>      version of Bind9 that doesn't log the resolver method.
>       <param name="requesttype-distribution"/>
>       <param name="requests-by-period">
>         <param name="period">1d</param>
>       </param>
>       <param name="requests-by-timeslot">
>         <param name="timeslot">1h</param>
>       </param>
> -->
>       
>       <param name="requesttype-by-method"/>
>       <param name="req-by-period-by-method">
>         <param name="period">1d</param>
>       </param>
>       <param name="req-by-timeslot-by-method">
>         <param name="timeslot">1h</param>
>       </param>
> 
>       <param name="header">Recursive Requests</param>
>       <param name="select-resolver"> <!-- filter -->
>         <param name="method">recurs</param>
>       <param>
>       <param name="top-requesting-hosts">
>         <param name="hosts_to_show">10</param>
>       </param>
>       <param name="top-requested-names">
>         <param name="names_to_show">10</param>
>       </param>
> 
>       <!-- filter ends here, but how can we tell? -->
> 	  	  
>       <param name="header">Non Recursive Requests</param>
>       <param name="select-resolver">
>         <param name="method">nonrec</param> <!-- filter -->
>         <param name="top-requesting-hosts">
>           <param name="hosts_to_show">10</param>
>         </param>
>         <param name="top-requested-names">
>           <param name="names_to_show">10</param>
>         </param>
>       </param>
>     </param>
> 
> Pros:
> • The report gets selected using the usual config mechanism (we'd have to
>   activate the "services" sections for that).
> • It uses standard Config components.
> 
> Cons:
> • The filtering scope is not explicit (it's another layer on top of the XML
>   structure, in a sense).
> • There's still no differentiation between different schemata. (But that
>   can be added).

I do like this way of storing the report configuration. (We don't yet
need another XML markup). The way to interpret each param is determined
by the config specificaiton which is consistent with how the things are
done now. 

I agree that the filtering scope isn't determined by the XML structure,
but this is really a limitation of the current implentation (both in the
ReportConfig object model and in the report generation algorithm). We
can either try to fix this before or after moving to the XML report
configuration. I don't think it's a nice idea to try to fix both
problems at once. 

The idea is that the configuration framework should build the
ReportConfig object from that XML definitions.

Instead of activating the "services" section, I would rather have a
"reports" section to the configuration file. This section would only
contains report configuration definitions. 

I really think we should phase out the superservice/service concepts,
since it will confuse things when multi-schema support is really
working.

Francis J. Lacoste

-- 
Francis J. Lacoste              . .           http://www.logreport.org
/^LogReport$/               . .               flacoste 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/20030609/c922b32b/attachment.bin