Lua Cheia Architecture

wiki

Difference (from prior major revision) (minor diff, author diff)

Changed: 6c6

a) enums all availeable Modules

a) enums all available Modules

Changed: 11,13c11,14

==Handling of statical linking vs. dynamic linking==
* The second level (ModuleLuaCheia?) enumerates all availeable Modules. These could be statically linked (always available) or dynamically linke (on demand). In the later case, moduleLuaCheia need to be able to 'scan' it's installation folder for available Modules.
scanning the folder would be non-ansi, but it is not really needed. you can just try to load the appropriate dll (or lua script, or any combination in any order). of course it will be an error if you can't find any matching file. You can't "enumerate" all available modules in this way, but i guess this is a feature that is not of much use anyway ;)

==Handling of static linking vs. dynamic linking==
* The second level (ModuleLuaCheia?) enumerates all available Modules. These could be statically linked (always available) or dynamically linked (on demand). In the later case, moduleLuaCheia needs to be able to 'scan' its installation folder for available Modules.
- scanning the folder would be non-ansi, but it is not really needed. you can just try to load the appropriate dll (or lua script, or any combination in any order). Of course it will be an error if you can't find any matching file. You can't "enumerate" all available modules in this way, but i guess this is a feature that is not of much use anyway ;)
- the reason was to have a 'query' function that can return info about available modules w/o loading them. a) available? b) version? etc. The scanning will be done by a special LuaCheia Module, containing fs functions (which will not be ANSI C, but portable) --MartinSpernau

ideas collected from the lua-l. --MartinSpernau

LuaCheia Core

BjornDeMeyer? proposed a three level Architecture:

First level would be a standard Lua interpreter with only a single module added (let's call it ModuleLuaCheia?)
Second level would be the moduleLuaCheia, which

: a) enums all available Modules
: b) handles loading of the various Modules transparently (LuaBinaryModules, Script Modules, whatever)

Third level are the actual Modules

the Second Level would the ideal place to customize the behavior of LuaCheia. Here one could add security related features (trusted Module?) etc.

Handling of static linking vs. dynamic linking

The second level (ModuleLuaCheia?) enumerates all available Modules. These could be statically linked (always available) or dynamically linked (on demand). In the later case, moduleLuaCheia needs to be able to 'scan' its installation folder for available Modules.

: - scanning the folder would be non-ansi, but it is not really needed. you can just try to load the appropriate dll (or lua script, or any combination in any order). Of course it will be an error if you can't find any matching file. You can't "enumerate" all available modules in this way, but i guess this is a feature that is not of much use anyway ;)
: - the reason was to have a 'query' function that can return info about available modules w/o loading them. a) available? b) version? etc. The scanning will be done by a special LuaCheia Module, containing fs functions (which will not be ANSI C, but portable) --MartinSpernau

RecentChanges · preferences
edit · history
Last edited February 18, 2003 5:50 pm GMT (diff)