On 4/9/00 11:38 AM Jeremy Wadsack ([EMAIL PROTECTED]) wrote:
>> The first part starts off with a summary of site-specific "interesting
>> pages" -- this list is in a quasi-hierarchical form, and includes hits to
>> static pages, total hits to the machine tool databases, hits by area (the
>> main Techspex area is cobranded
>> for five other companies, so we do comparative traffic analysis to see
>> whether their marketing is really buying us anything.)
>
>This could be done in either Analog or Report Magic.
>> We do incredibly detailed analysis of number of hits to each advertiser's
>> vital information, and searches executed on them, and similar but less
>> detailed analysis of the tools searched for. (Odd. That seems backward but
>> that's life, I guess.)
>
>This could be done with specific runs of Analog using REQINCLUDE
>statements and ARGSINCLUDE statements. Then combining it, via a script, with
>your other reports.
These, and serveral of the other requests in the original post, can be
done by running Analog several times with different configuration
settings each time. I've setup 'Interesting Hits' reports for people
using combinations of filtering and aliasing several times now.
I see three routes to supporting this. 1) run Analog once on the logs to
produce a cache file and then run Analog several times on the cache file,
2) redesign Analog to allow multipule copies of the same report with
different configuration settings in a single pass, 3) run Analog once to
produce a computer output file and then run something else (like
ReportMagic) to pull items out in the correct organization. The way the
code is written right now, the first and third approachs seem much
simpler to get going. I'm afraid that the third approach may result in a
loss of generality, many settings must be the same for the different
reports pulled from one Analog run. The first approach seems like it
would have to be slower to run just because of all the times Analog would
be loading the cache file and again the cache file restricts some
settings to being the same across runs.
Stephen, do you have any thoughts on this. Would it be better to write
some kind of shell around Analog that runs it multipule times or would it
be better to generalize the code so that it could allow multipule reports
on the same datatype with different configurations? Keep in mind that we
appear to be talking about a whole bunch of different runs for each
complete report. Changing Analog directly would also be more portable.
The shell approach is simple to impliment on Unix, but it is quite tricky
on Windows and Macintosh. On the other hand the shell would leave the
exisiting Analog code alone and makes it simpler for someone else to do
the work.
I can imagine reorganizing the Analog code so that there is a global list
of report definition records, such that there is no explicit linkage
between data types and reports. Several of the structures are already
setup for this, but I'm not clear on all of the implications to other
parts of Analog.
Thoughts?
Jason
-----------------
[EMAIL PROTECTED]
-----------------
Dr. Seuss books . . . can be read and enjoyed on several levels. For
example, 'One Fish Two Fish, Red Fish Blue Fish' can be deconstructed
as a searing indictment of the narrow-minded binary counting system.
-- Peter van der Linden, Expert C Programming, Deep C Secrets
------------------------------------------------------------------------
This is the analog-help mailing list. To unsubscribe from this
mailing list, send mail to [EMAIL PROTECTED]
with "unsubscribe" in the main BODY OF THE MESSAGE.
List archived at http://www.mail-archive.com/[email protected]/
------------------------------------------------------------------------
