Re[2]: [yaala] So, lets actually do something...

Thu, 4 Dec 2003 21:28:41 +0600

On Wednesday, December 04, 2002, 7:58:27 PM, Florian wrote:
FF> The storage is propably the most important and the most difficult at the
FF> same time, so we should start with it.

>> I guess, the optimal way is:
>>   $hash->{$keysequence_def}{$val1}{$val2}{$val3}{$expr_def}

FF> Sounds good :) Is expression something like 'SUM(bytes)' ?
I suggest expressions to be random combination of fieldnames,
constants, functions, arythmetic, string and booleand operators.
These expressions are to be parsed upon configuration stage,
and $expr_def is refenence to structure holding parsed expression.
I think it would be nice to store expressions in lisp-style,
in recursive lists in form ($operator $loperand $roperand):
TOTAL(bytes) / (SUM(bytes)/COUNT(days)) * 100 -->
( *
  ( /
    (total bytes)
      (sum bytes)
      (count days)))
>> Parser itself has no interface at all - it should only provide data
>> labels and types, and then use data::store()
>> There's nothing to configure in general.

FF> Well, the webserver-parsers do need to know the own domain-name(s) or how
FF> exact you want the referers, the netacct module needs to know about
FF> subnets and their names, so there is the need to load additional
FF> configuration files, since I don't want to have all that in the main
FF> configuration. See lib/ (added in 0.5.1)

Well, then maybe it would be good to have global @config_options with
strings presentation of all config options given,
and then each module will look up this hash/array for
options it needs and parse it by itself.

FF> Well, I could start writing the new Data::store_data routine, if you want
FF> me to. Just let me know :)
I'm now going to code selection-gramma parser and expression evaluation.
If u have clean vision of how store_data should work, just go ahead :)

FF> Yeah, one more thing: If you rather want your real name appear on the
FF> Homepageor so, just let me know that, too ;)
I dont have real name :))))))))))