Re: Embedding - user inputted scripts design advice

[Bruce Wheaton <bruce@...>]

Thanks Sean. I like that idea - designate some specific items we will persist, and then flush the rest. By default, the user stuff would be flushed unless they move it to some specific table I can protect. That sounds like the plan.

Bruce


On May 14, 2012, at 4:42 PM, Sean Conner wrote:

> It was thus said that the Great Bruce Wheaton once stated:
>> What's the usual way to deal with the user changing their scripts in an
>> app with embedded lua scripting? I presume I really have to reset the lua
>> state in some way, so any functions that were defined (or variables) that
>> they no longer want are removed correctly?
>> 
>> Is there an accepted way to retain values of the items that they did
>> leave, to help with the case of a simple change, like to a calculation?
>> 
>> And then is it usual to reset and rebind all external class/object
>> bindings, or is a 'soft' reset possible?
> 
>  It really depends upon the use case.  You can reset the Lua state (or
> rather, close it, then re-open and re-initialize a new one), or re-use the
> existing Lua state.
> 
>  For syslogintr [1] I don't bother with resetting the Lua state at all if
> the given script is reloaded.  I do, however, do this (from [2]):
> 
> 	if blocked == nil then
> 	  blocked = {}
> 	  setmetatable(blocked,{ __index = function(t,k) return 0 end })
> 	  os.execute("iptables --table filter -F INPUT")
> 	end
> 
> to keep from resetting some persistent data [3].  But in general, there are
> no hard and fast rules.  
> 
>  -spc
> 
> [1]	http://www.conman.org/software/syslogintr/
> 	https://github.com/spc476/syslogintr
> 
> [2]	https://github.com/spc476/syslogintr/blob/master/modules/ssh-iptables.lua
> 
> [3]	This module of syslogintr tracks failed ssh attempts, and after five
> 	attempts, will block the offending IP address.  The blocks are
> 	removed after a few hours to keep the ruleset in iptables from
> 	ever-increasing.
>