RFC: LogReport Architecture

[Joost van Baal]

On Fri, Jun 22, 2001 at 03:53:44PM -0400, Francis J. Lacoste wrote:
> On Fri, Jun 22, 2001 at 08:11:29PM +0200, Egon Willighagen wrote:
> 
> >  My comments are started with ****:
> 
> Mine are now prefixed with ++++

Mine are not prefixed with '> '.

> LogReport Architecture Discussion and Proposal
> 
> 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.
> 
> **** i did not find writing a report hard, i thought it was quite 
>      easy actually. 
> 
>      The interfaces are also not that hard:
> 
>      INPUT: DLF for specific superservice
>      OUTPUT: report which uses the LogReport DTD
> 
>      Moreover, consider that developing this part of Lire has developed
>      less... i am not sure we should drop the efforts made.
> 
> ++++ I guess, I found it difficult because of my personal dislike for
>      complex shell scripting :)

I am not afraid of dropping code if it later turns out to be badly
designed, even in cases when the amount of code is big.

> The problem is that report information is scattered in lots of file
> which are linked trough various indirection of environmental
> variables.
> 
> **** this is true. And again the cause is the short live of the code
>      included. At this moment reports consist of these files:
> 
>      1. the report itself
>      2. OPTIONAL: an configuration file
>      3. OPTIONAL: an description
> 
>      A frontend to these file is not hard to write.     

But is _is_ hard to make it possible to get a new report script
generated by clicking on a gui.  My understanding was that
this is what we're finally going for.

> 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.
> 
> **** not sure this is really true... all configuration is now done
>      by keywords... a keyword more or less does *not* involve changes
>      to the GUI
> 
>      I do agree that help is not available much at this moment, though
>      the convention is to give comments in the config file as help
> 
>      This could easily be formalized (e.g. an XML format)
> 
> ++++ I really dislike fiddling with eval and environment variable for
>      interpreting dynamic complex structure in the shell. But I guess this
>      is a matter of taste. 

It's hard to safely deal with this kind of tricks.  Good errorhandling
while doing evals is next to impossible.

But, Egon, were you talking about e.g.

 ITEMS=30
 PAGES=5

in etc/www/report_pagesperclienthost.conf ?  There is no eval-ing
involved there.

We seem to be talking about two things: making it possible to configure
existing reports using a gui, as well as making it possible to define new
reports using a gui.  I agree with Egon: to facilitate the first thing,
we don't need to change _that_ much of the existing infrastructure.

However, I'd like to be able to do the second thing also.

>      That is why I proposed an XML format for packaging all the 
>      informations about a subreport.
> 
> Proposal of Modifications to the Report Generation Architecture
> ---------------------------------------------------------------
> 
> One solution would be to replace the subreport-is-a-program paradigm
> with the use of a report specification language. Like the XML report
> format that we presently have, the report specification language would
> be XML based. It would contains in a structured document the
> description of the various subreport and the description and type of
> the various parameters that can be customized.
> 
> **** i vote against dropping the subreport-is-a-program paradigm.
>      Simple reason: i need the flexibilty when making advanced
>      subreport this summer... I will need to do things which you cannot
>      do in SQL, or any scripting langauge.

What plans do you have?

>      this does not necessarily mean that *all* subreport have to be
>      a program (perl/shell/c/java/python/ruby or whatever)...
> 
>      As a 'counter' solution i would vote for a "general" subreport
>      program which is able to deal with subreport generating scripts
>      (subreport-is-a-sscript paradigm)...
> 
> ++++ The counter solution is interesting. But I would like to see 
>      an example of "advanced subreport" that can't be express in 
>      "crippled" language.
> 
>      But I really like the idea of making easy thing easy and complex thing
>      possible. So the general program with escape is still interesting.
>      
>  
> The lr_dlf2xml program would be replaced by a program which reads the
> XML report specification and process the DLF database accordingly to
> generate the XML report. All the information needed to understand a
> report would be self-contained in one file. (Of course, this file
> could be split up for convenience through the use of XML entities;
> reordering the report would only mean reordering the entities.)
> 
> **** not sure what we would gain if we would place all info/script/etc
>      in one file and then split it up again... Except for the fact that
>      it would be parsable more with only one run...
> 
> ++++ I would only split up the subreport. All information about a subreport
>      should be in one file. 
> 
> This solution would make it easier to write new subreport, to develop
> a GUI to customize the report generation process and would also make
> it easier to localize. In this scheme, the xml-i18n-tool which can
> localize static XML files can be used to localize the report
> specification.
> 
> 
> **** i guess to solve this, i would propose that the subreport itself
>      describes the GUI it needs...
> 
> ++++ yes, that was the idea, throught the use of <param> element and
>      other meta-informations. I'm not arguing for including the GUI 
>      through a programming language tough.
> 
> We should also note that modification of the report generation
> architecture is somewhat orthogonal to the use of SQL. We can easily
> imagine that the report specification processor uses SQL to build the
> report. More, if we want to support an environment where there is no
> need to install a full-fledge SQL server, we could write an processor
> for the same report specification which works with ASCII DLF file
> (altough it would be probably slower and more difficult to write).
> 
> There is some limits though. First, this is a lot less flexible than
> the current approach where we have a Turing-complete language to
> generate the subreport (the complete Shell or Perl language). 
> 
> **** i cannot stress this aspect enough :)
> 
> ++++ what i want to stress is that you don't have to use a Turing-complete
>      environment for simple things. 

Exactly,  the queries we currently answer are _far_ more easy than
the tools we use to formulate them.

<big snip of interesting ideas>
> 
> **** Good argument against using just SQL as an interface to the "DLF"
>      data (wether as file, or as DB content...)
> 
> ++++ This is a matter of deciding if we want to require a SQL server
>      or implement aggregates and functions in SQL::Statement.

I'd be very much in favor of being able to fire of queries in an
sql-like syntax _without_ being required to set up an sql server.

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