[Sputnik-list] proposed versium modifications

[Jim Whitehead II]

On Mon, Mar 3, 2008 at 7:55 AM, Yuri Takhteyev <yuri at sims.berkeley.edu> wrote:
> 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:

This seems to naturally lie between Sputnik and Versium in the
architecture.  I would suggest it either ends up in its own rock
(seems excessive) or lands in Sputnik proper, since it won't be called
outside that context.

>
>     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.

Ah, didn't realize that something in versium itself used it.  In that
case, I would make it a simple rock.  Rings actually creates full lua
states and allows message passing between them.  This is a nice,
simple, no-frills way to execute code in a sandbox.  It seems to make
sense to break the tie with versium.

- Jim