Lua + lubev + sandboxing
git clone
Log | Files | Refs | README | LICENSE (3684B)

      1 About
      2 =====
      4 Mooa is a work in progress. The ultimate intent is to create a
      5 multi-user, interactively and collaboratively programmed network
      6 server. Its inspiration is the original author's (Sean Lynch)
      7 experience with LambdaMOO, MUSH, and LPMUD, and ColdX/Genesis. Its
      8 primary application is intended to be a textual shared interactive
      9 environment accessed via web browser. Kind of like a chat server, but
     10 programmable entirely from within the environment.
     12 Requirements
     13 ============
     15 * Lua 5.1
     16 * libev
     17 * udns
     19 Building
     20 ========
     22 There is not yet any autoconf or anything like that, so edit the
     23 makefile and then run "make". Hopefully you'll get an executable out
     24 of it.
     26 Running
     27 =======
     29 Edit main.lua and put interesting stuff there, then run
     30 "./mooa". Something interesting will hopefully happen. For now you
     31 will have to read the source to have any idea what's going on. The
     32 APIs are in flux so it seems kind of pointless to document them, at
     33 least until I figure out how to automatically generate useful docs
     34 from the code.
     36 FAQ
     37 ===
     39 These are questions that are frequently asked only in my head, because
     40 I am writing this before anyone has actually seen the software. And
     41 even after I put it up on Github, I doubt many people will see it
     42 except for bots that scrape Github looking for particular keywords and
     43 languages so recruiters know who to send their barely targeted generic
     44 emails looking for "rockstar X coders" to, completely ignorant of the
     45 fact that you have code written in 10 different languages among your
     46 contributions and your only code in language X is just a fork of
     47 another repo with only very minor tweaks.
     49 Why Lua?
     50 --------
     52 I would have preferred Javascript, but neither V8 nor SpiderMonkey is
     53 really targeted at embedding. Both their APIs are constantly
     54 changing, they are poorly documented with much of at least
     55 SpiderMonkey's documentation being out of date, and V8 has a rather
     56 complex C++ API. The only C/C++ JavaScript implementation that's
     57 targeted at embedding is mujs, and its license is extremely
     58 restrictive.
     60 Lua, on the other hand, has a stable, extremely well documented API,
     61 is specifically targeted at embedding, and is licensed under the
     62 MIT license, which doesn't require any mental gymnastics to call it
     63 "free as in freedom."
     65 You should use JS anyway
     66 ------------------------
     68 You're probably right, but if I use JS I won't be able to motivate
     69 myself to write the damn code. Complex, poorly documented, constantly
     70 shifting APIs directed at a completely different use case are not
     71 exactly enjoyable to use.
     73 Use node.js. It has a sandbox
     74 -----------------------------
     76 That's not a terrible idea, but I envision high concurrency and low
     77 latency. Having separate processes that have to hang around even if
     78 the code running in them is blocked on IO or sleeping doesn't scale
     79 incredibly well. On the other hand, my approach will probably have
     80 more security holes. I will probably at least have trusted and
     81 untrusted Lua code running in separate processes in their own
     82 namespaces and sandboxed with SECCOMP, but it seems likely that I will
     83 have all untrusted Lua code sharing the same process sandbox, isolated
     84 only by not having any mutable shared state. I don't yet know whether
     85 that means separate Lua runtimes, however. That will require some
     86 experimentation.
     88 Something is broken
     89 -------------------
     91 This thing is nowhere near being in a releasable state. Please feel
     92 free to report issues if you think there are fundamental design flaws
     93 or you think I should change how something works, but don't expect it
     94 to be actually useful for anything yet. So stuff like "you're doing
     95 this wrong" is fine, but "I can't use this for X" is not.