UNSUBSCRIBE

[Ruck, Michael]

-------------------------------------
it-novum GmbH
Weyherser Weg 8
36043 Fulda
Deutschland

Tel: 0661-103706
Fax: 0661-10317706
eMail: mailto:m.ruck at itnovum.de 
Internet: http://www.itnovum.de

>>-----Ursprüngliche Nachricht-----
>>Von: Francis J. Lacoste [mailto:flacoste at logreport.org] 
>>Gesendet: Donnerstag, 5. Dezember 2002 23:45
>>An: development at logreport.org
>>Betreff: PROPOSAL: Configuration Framework and Extensibility
>>
>>
>>Looking at the current path we are going with the 
>>configuration framework, I'm not sure that the idea of 
>>expressing the configuration requirements in a separate XML 
>>files is practical. 
>>
>>I feel that it needs to be closer to the implementation of 
>>the various plugins. What I'm thinking of is to define 
>>something like a perl interface which could be used by all 
>>extension modules (DLF converters, analyzers and output 
>>plugins). Configuration not tied to a "plugin" could also be 
>>specified using this interface. The configuration 
>>specification would be expressed through a perl data 
>>structure returned to the configuration framework. 
>>Configuration specification would be registered with the 
>>framework by placing a small file in the appropriate directory:
>>
>>$datadir/lire/config
>>  
>>There would be a subdirectories in there for each kind of 
>>group of configuration specifications:
>>
>>  general -> place that contains configuration requirements for the
>>  whole framework.
>>
>>  schemas -> configuration specifications related to a schema
>>
>>  convertors -> holds the registration files for DLF convertors
>>
>>  processors -> holds registration files for output drivers and XML
>>  report processors.
>>
>>  analyzers -> holds registration files for analyzers.
>>
>>The registration file would simply contains the name of the 
>>perl module to get the configuration specification from.
>>
>>The perl module would then define some functions which 
>>returns the data that will make up the configuration 
>>specification that our configuration framework can use.  Example:
>>
>>package UserDataSessionConfigSpec;
>>
>>use base qw(Lire::Config::Spec);
>>
>>sub register_config {
>>    my ( $self, $config_framework ) = @_;
>>
>>    $config_framework->register_config( 
>>        label => 'Configuration for User Session Analyzer',
>>        description => 'help description',
>>
>>        # Other configuration specification that this required
>>        # by this module
>>        depends => 'lire_general',
>>
>>        params => [
>>        {
>>            name => 'page_re',
>>            type => 'regex',
>>            label => 'Page Regular Expression',
>>            description => 'Regular expression used by the analyzer to
>>        determine if a request is a page or not.',
>>        },
>>        {
>>            name => 'session_calc_mode',
>>            label => 'Way to determine session',
>>            type => 'enum',
>>            default => 'ip_useragent',
>>            description =>  'There are several way to determine ...',
>>            values => [ qw/cookie ip_useragent/ ],
>>        },
>>        ];
>>   );
>>}
>>
>>sub validate_config {
>>    my ( $class, $config ) = @_;
>>
>>    # Make sure that the current configuration can be used
>>    # and throw errors if not.
>>
>>    my $mode ==  $config->get( 'session_calc_mode' );
>>    if ( $mode eq 'cookie' ) {
>>       # Make sure that the cookie_name parameter is set
>>       $config->missing_value( 'cookie_name' );
>>    }
>>}
>>
>>The configuration framework would then be responsible for 
>>loading all the modules defining configuration elements. It 
>>could provide common validation methods that could be used by 
>>the configuration specification module.
>>
>>Somehow it seems easier and cleaner to implement than the XML 
>>based configuration specification. Thinking of it, I can't 
>>see any advantage to the XML based specification. (I really 
>>feel bad about this, since I was the one who insisted on this 
>>initally...) Even automatic documentation generation could be 
>>generated by the configuration framework. The description 
>>values could contains DocBook (or POD markup). This also 
>>makes the validation of the configuration more flexible since 
>>all checks can be programmed. And it also makes the 
>>configuration closer to the code that uses it (the DLF 
>>converters, output plugins, analyzers which are all perl modules).
>>
>>We also have a nice classification of the configuration task 
>>(matching the directory and module hierarchy), as one could 
>>define common parameters to a schema (like the page_re 
>>parameter) in a configuration module that can be depended on 
>>by the analyzers or converters needing it.
>>
>>I think that storing the configuration in a XML file like we 
>>decided is still a good idea. Especially if we move the 
>>report configuration there also.
>>
>>Comments, suggestions, and flame for over-engineering things 
>>with bogus requirements in the first place are welcome.
>>
>>
>>Francis J. Lacoste
>>
>>-- 
>>Francis J. Lacoste              . .           http://www.logreport.org
>>/^LogReport$/               . .               flacoste at logreport.org
>>

-- 
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