Joined: 08 Oct 2006
|Posted: Sat Jan 12, 2008 8:56 pm Post subject: Global application repository
|From a letter of mine to Jeremy...
One of mine ideas
Do you remember the talk about the load path that a script may be willing to know?
The effect is this:
gian@hplin:~/Progetti/falcon/projects/faldoc/tests/samples$ falcon -L ../../src ../../src/faldoc.fal simple.fd
faldoc - Falcon documentation tool.
Part of the Falcon Programming language.
faldoc: FATAL ERROR - Cannot find or load module (faldoc_output_)html
It's obvious; the load directive works because I passed -L ../../src on the command line, but the script (and it's Compiler() instance) has not this information.
On firsts, I just thought to add a falconLoadPath global variable to be filled as it's done now with args, scriptName and scriptPath.
This would work, would be enough and would be easy to do, but I thought a step forward: it would be nice to have a more flexible interface called vmInfo(); you may pass "loadPath" to it to get the "expected" load path, and so on.
Then I thought a step forward again. The point is, what happens in the "final stage", when we install faldoc on the target machine?
We'll have faldoc.fal somewhere in the system, possibly not on the standard load path; its static
modules (i.e. in this moment faldoc_version and faldoc_parser) *should* not be in the standard load path anyhow (this for code cleanness) and finally the dynamic modules (as i.e. the output modules) may still be somewhere else.
Who has this informations? -- the installer.
How can we pass those informations to a deep script creating an instance of the Compiler() class?
One way would be that of add everything to the load path through a .sh in the bin/ dir; something that may call
falcon -L<path_to_faldoc>;<path_to_faldoc_mods>;<path_to_faldoc_dyn_mods> faldoc.fal $*
But this is tricky and far from portable. Also, this would solve the problem when we just have a path to pass, but what about other resources?
So, how can the installer pass the informations to the script?
One way would be that of messing up with the sources, and hardcoding the parameters into them at installation. But I would hate such a solution, as it would prevent using pre-packed binary archives.
For once, a good idea came from Windows.
What about a central registry of application information?
The file /etc/falcon.ini (or any other file) may contain sections holding variables that may be accessed by scripts through a common interface, as i.e. an extension of the config parser.
I.e. a SysConfigParser() instance would automatically detect the system-wide configuration, searching <scriptName>.ini and then falcon.ini in sensible places, automatically loading a configuration and importing configuration dictionary as sensible.
In this way, each falcon "application" may be known at system level, and it may access those information read-only; then the application may still configure itself for finer tasks.
For the moment, I am just adding the variable, as we must concentrate on making the loader to work, but i would like to have more opinions.[/i]