ideas collected from the lua-l. --MartinSpernau
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 6:50 pm GMT (diff)