Hi Sean, An alternative approach you might consider instead of relying heavily on sandboxes and namespaces is to define your own #lang where you can carefully control how different objects are allowed to communicate with each other. This approach could have two advantages: 1) you can use lighter-weight mechanisms to represent objects, and 2) you can restrict things to make it much less likely that you would get bitten by a misunderstanding how namespaces and require, etc, work.
We used a similar approach when writing Shill, our capability-based shell scripting language based on Racket (shill-lang.org). You can find a short description of how we did this in section 3.1 of the paper ( http://shill.seas.harvard.edu/shill-osdi-2014.pdf). Cheers, Scott On Tue, Aug 18, 2015 at 12:48 AM, Sean Lynch <se...@literati.org> wrote: > Hi, folks. I'd like to implement an LPMUD-like multi-user programmable > environment in Racket. The idea is that an "object" would be a module plus > some state, similar to a gen_server in Erlang. Objects would each live in > their own sandbox and communicate with one another via message passing, > probably via channels. > > So far so good; despite my inexperience with Racket, I am fairly certain > this should be straightforward to implement. And a sandbox per persistent > object and message passing between them doesn't seem like it would be too > high a price to pay, since this is what Erlang does, and it's similar to > what LPMUD and MOO and Genesis do. > > However, users nee to be able to extend and reuse one another's code, and > I'd like them to be able to do that without having to trust the code not to > leak private state or affect their own code's behavior in unexpected ways. > It seems like I can use contracts to some extent to help users from > accidentally passing or returning excessively powerful capabilities > (however I implement those: proxies, closures, etc); But at the very least > I know that any function called in a "require"d module can inspect and > modify the current namespace, which will affect dynamic code even if it > doesn't affect module code. And I imagine there are probably other > introspection functions that could enable access at least to any state > stored in top-level variables. > > So my question is: assuming it is even practical to protect state from > code in "require"d modules running in the same sandbox, what would be the > best way to go about this? Or are sandboxes and channels (or some other way > to pass messages between sandboxes) cheap enough that that's the best way? > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout > <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=vNTo0BhTaa0rf5fiErRpax-tpq3uFcfyQMrQ0pZ_dcc&s=xIiHlc9nqPBTsx6n-KUJPsWMGd6iTGjpZyp6arDHCJo&e=> > . > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
