RFC: LogReport Architecture

[Joost van Baal]

On Fri, Jun 22, 2001 at 04:20:03PM -0400, Francis J. Lacoste wrote:
> On Fri, Jun 22, 2001 at 09:28:05PM +0200, Joost van Baal wrote:
> > <snip>
> >
> > > Limits of the Present Architecture
> > > ----------------------------------
> > > 
> > > I think that the biggest problem of the current architecture is in the
> > > report generation process. Adding a report and customizing report is
> > > very tedious both for the developer and for the user. The other two
> > > interfaces are pretty good and seems extensible. 
> > > 
> > > The problem is that report information is scattered in lots of file
> > > which are linked trough various indirection of environmental
> > > variables. Also, customization of the subreports aren't standardized.
> > > This means that writing a GUI to make it easier for the user to
> > > customize the report would be very tedious because there isn't any
> > > meta-information about the available subreports (what parameters can
> > > be modified, what are their meaning, etc.). Each modification to a
> > > subreport or addition of a subreport would mean changes to the GUI.
> > 
> > The problem here is, i believe, that it's currently next to impossible
> > to automatically generate a report_whatidliketoknowtoday script.
> 
> I don't understand what you mean here ?

I mean, specifying, by e.g. clicking on a gui, a query like

 Give me the top 15 biggest messages, along with their
 receiving email address and time sent.  Display like

 joe at domain.com              100M
   200106011230               50M
   200106011235               50M
 ann at otherdomain.com          70M
   200106011230               50M
   200106011232               20M

The code generating such a report should get generated from the
clicks on the gui.

> <snip>
> 
> > > 
> > > Also this ties us to SQL which will make LogReport requires a full
> > > fledge SQL database for the SQL::Statement module (which is used for
> > > the DBD::CSV and DBD::File drivers) doesn't support aggregates (GROUP
> > > BY) nor functions (hour(timestamp).
> > > 
> > 
> > I take this for granted.  I am not really well introduced to the
> > various xml tools yet.
> > 
> > BTW, is there a perl module which makes a simple ascii file accessible
> > via sql statements?  I know there's a module which makes such a file
> > accessible as a database.  If there is such a thing, I'd like to
> > see it, and see it answering a simple sql statement.
> > 
> 
> The perl module to access ascii file through SQL statements are 
> DBD::CSV and SQL::Statement. They don't support aggregates and
> functions so that make them useless for our purpose. 
> 
> For example, these query don't work
> 
> SELECT url, sum(bytes) FROM www  GROUP BY url
> 
> SELECT to_domain, sum(msg_count) FROM email GROUP BY to_domain 
> 
> I didn't evaluate the complexity of adding those features to the
> module. (That could be an option)

If the only alternative is requiring an sql server, I think we should
seriously consider adding such functionality.  BTW, querycalc was started
with a similar idea (though development on that script stopped.)

Bye,

Joost



-- 
To UNSUBSCRIBE, email to development-request at logreport.org with a subject of
"unsubscribe". Trouble? Send an email with subject "help" to
development-request at logreport.org