[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [LuaCheia] Let it begin.
- From: RLake@...
- Date: Tue, 11 Feb 2003 17:17:46 -0500
Martin Spernau escribió:
> I agree. But couldn't that also be done for Lua4? Returning the module
> functions in a table , that is?
Yes, but it is not as convenient. You have to put the table somewhere;
Lua 4 upvalues are a bit of a pain because you end up having to repeat
them into every function definition (although I did get used to that)
so you end up putting it into a global, but then you get name collisions.
The nice thing about lexical bindings is that names can be lexically
bound to a file, so there are no cross-file collisions. Under those
circumstances, globals are much less important.
> <snip of several good suggestions>
> Well, my comment would be: security etc. is important... But im concerned
if
> this might not go 'overboard' slightly.
> My personal wish for Lua (and also LuaCheia) would be to have maximum
> flexibility and modularity. And that also means that I do not need an
admin
> to install stuff for me. The ideal Lua distribution for me consists of
one
> or only a few files I can put where they are suitable to me, and run
them.
I agree. The default installation should probably put the files it needs in
your home directory or equivalent. I'm very nervous about searching for
binary DLLs/SOs in "all the usual places." However, the solution I outlined
(I think) would make it easy to generate a reasonably usable and reasonably
secure default install, whilst permitting a web-administrator or other such
beast to create a safe system-wide install.
> That's the exact goal why Python, Perl, PHP, Ruby don't cut it for me,
ease
> of distribution.
> Ideally _nothing_ needs to be installed to run a LuaCheia app.
That would be the implementation of the old "Read Programmer's Mind"
instruction, no? :)
> And then, if you look at CGILua, that implement just what you are
proposing
> re security. A core that get's run by root (the server), then sets up an
> restricted env and runs custom code as user.
Yes. The issue is how to set up the restricted environment. I think that
needs to be thought through in advance. The goal is to make it easy to
create an environment that is restricted enough without being too
restricted.
For example, a restricted environment which could not use the module system
at all would be too restricted.