I think what you are suggesting is using a communications protocol of some sort, which was a little more than I was thinking, but a very good idea none the less... (gotta remember to think outside the box)

As far as the application architecture, I was looking to create a hub and spoke effect... contoller module plus all the functional modules working independently of each other... the technical architecture would be layered and statically available for all. The architecture problem I inedequately described was the simple fact that I can't keep good help arround. I must build something that is flexible enough to allow anyone with some perl skills to plug in a new functional module without much experience or knowledge of the whole system.

I guess the quick answer (and hopefuly simplest)I was looking for was what are my options if I want to be able dynamically load modules into a perl program and then subsequently call them through out the program. From the research I've seen it might be possible to open the config file, parse through and loop through with an "eval" statement at every module...

Functional interaction between modules would again be determined by config file at load time.

This might a lot of work for little reward, but damn... the concept of it sounded pretty cool at work...

Cheers

> I think what you are suggesting is using a communications protocol of
> some sort, which was a little more than I was thinking, but a very
> good idea none the less... (gotta remember to think outside the box)

Whoops.. accidentally fell into personal shorthand when talking to someone outside my own head. I didn't mean 'protocol' in the sense of adhering to TCP/IP, COM, or some other established standard. What I meant was something along the lines of 'implementation independent interface specification'.

See, when I think 'interface spec', I think about function signatures:

    set_value (hash_key: string, key_value: string) : nil
    get_value (hash_key: string) : string
[download]

and while that's a necessary step on the road to shippable code, it's a truly rotten place to start. There's too much detail, and it's far too easy to get so bogged down in the minutae of 'how it works' that you lose sight of the big question: 'what does it do?'

So.. I was really just suggesting you decide how to partition the system, then figure out what the pieces need to say to each other.


> I guess the quick answer (and hopefuly simplest)I was looking for was
> what are my options if I want to be able dynamically load modules
> into a perl program and then subsequently call them through out the
> program. From the research I've seen it might be possible to open the
> config file, parse through and loop through with an "eval" statement
> at every module...

I think I see where you're going. Yes, you can eval() code into a program:

$code = <<DONE;
sub func {
    print "hello, world.\n";
}
DONE

eval $code;
&func;
[download]

and you can get that code from an external file:

$file = '/some/file/path';
open (CODE, $file) or die qq(can't read "$file": $!);

$tmp = $/ ; undef $/;
$code = <CODE>;
$/ = $tmp;

close CODE;

eval $code;

##  and then run some function defined in that code.
[download]

mike
.