[Sputnik-list] proposed versium modifications

[Yuri Takhteyev]

I've put together some of the ideas that have been thrown around into
a proposal for some (relatively minor) changes to versium.  Wondering
what you all think.

1. "Versium" will get cut down to the bare essentials.  It will
include just three files "versium.lua", "versium/util.lua" and
"versium/storage/simple.lua".   Maybe luaenv too.  Some alternatives
to simple.lua (e.g. versium.storage.svn) will be provided as separate
rocks.

2. The "extra" field in versium and the storage implementations will be dropped.

3. Storage implementations will need to support an extra method:
get_modification_time(node_name)  This will be expected to be a fast
method that would allow the caller to decide whether they need to
reload the node.  Implementations that don't know when their nodes
were last modified will be expected to return current time.

4. Implementations will be allowed to _not_ support history, saving,
or user names.  However, they are supposed to provide a "capabilities"
field which will state what they do and don't support.  In particular,
they should define capabilities.can_save and
capabilities.tracks_history.  Implementations that don't track history
need to just return a table with the latest revision when asked for
history.  Implementations that don't support saving should raise an
error when asked to save.

5. All the versium.smart stuff, present and future (prototypes, future
node composition, etc.) will go into a separate rock and will have its
own name.  (Suggestions for names are welcome.)  If we add indexing at
some point, this will go here as well.  Same for caching.

6. Not quite sure what to do with "luaenv".  "luaenv" is a very simple
library (<50 lines) to offer a fool-proof sandboxing interface.  The
main idea is that user submitted code will always be run through
"luaenv" and never directly through loadstring(), so that the
administrator doesn't have to worry about whether there is a missing
setfenv somewhere.  It also allows you a somewhat more flexible API
than fsetenv+loadstring: you can feed chunks of Lua one at a time, and
set or read values in the process.  Though, the most common usage
would simply be:

    values = luaenv.Sandbox:new{x = 1, y = 2}:do_lua("z = x + y")
    print(values.z)

Or am I reinventing the wheel here?  I've looked at Rings and it seems
to allow something similar, but it seems to default to giving the
slave state access to _G and it also a lot more complicated (than 50
lines of lua, that is).  My idea was to route all user code through
something that is really simple, so that I could say that if you
worried about security, you should audit luaenv.  Also, not sure where
it should go.  There is one function in versium.storage.simple that
needs it right now, so perhaps it make sense to make it a part of
versium.  Anyway, assuming luaenv stays, I want to change it to the
object oriented API (see above) from the current functional.

  - yuri

-- 
http://sputnik.freewisdom.org/