mooa

Lua + lubev + sandboxing
git clone https://code.literati.org/mooa.git
Log | Files | Refs | README | LICENSE

commit 0cc710d8ad7a36f59a1457211ccc351b675f4f78
parent ecbc00a83069ad4b05d8a556e8153e884ad3c592
Author: Sean Lynch <seanl@literati.org>
Date:   Mon, 23 Jun 2014 17:44:08 -0700

Add LICENSE and README.md

Diffstat:
ALICENSE | 21+++++++++++++++++++++
AREADME.md | 95+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 116 insertions(+), 0 deletions(-)

diff --git a/LICENSE b/LICENSE @@ -0,0 +1,21 @@ +The MIT License (MIT) + +Copyright (c) 2014 Sean R. Lynch + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN +THE SOFTWARE. diff --git a/README.md b/README.md @@ -0,0 +1,95 @@ +About +===== + +Mooa is a work in progress. The ultimate intent is to create a +multi-user, interactively and collaboratively programmed network +server. Its inspiration is the original author's (Sean Lynch) +experience with LambdaMOO, MUSH, and LPMUD, and ColdX/Genesis. Its +primary application is intended to be a textual shared interactive +environment accessed via web browser. Kind of like a chat server, but +programmable entirely from within the environment. + +Requirements +============ + +* Lua 5.1 +* libev +* udns + +Building +======== + +There is not yet any autoconf or anything like that, so edit the +makefile and then run "make". Hopefully you'll get an executable out +of it. + +Running +======= + +Edit main.lua and put interesting stuff there, then run +"./mooa". Something interesting will hopefully happen. For now you +will have to read the source to have any idea what's going on. The +APIs are in flux so it seems kind of pointless to document them, at +least until I figure out how to automatically generate useful docs +from the code. + +FAQ +=== + +These are questions that are frequently asked only in my head, because +I am writing this before anyone has actually seen the software. And +even after I put it up on Github, I doubt many people will see it +except for bots that scrape Github looking for particular keywords and +languages so recruiters know who to send their barely targeted generic +emails looking for "rockstar X coders" to, completely ignorant of the +fact that you have code written in 10 different languages among your +contributions and your only code in language X is just a fork of +another repo with only very minor tweaks. + +Why Lua? +-------- + +I would have preferred Javascript, but neither V8 nor SpiderMonkey is +really targeted at embedding. Both their APIs are constantly +changing, they are poorly documented with much of at least +SpiderMonkey's documentation being out of date, and V8 has a rather +complex C++ API. The only C/C++ JavaScript implementation that's +targeted at embedding is mujs, and its license is extremely +restrictive. + +Lua, on the other hand, has a stable, extremely well documented API, +is specifically targeted at embedding, and is licensed under the +MIT license, which doesn't require any mental gymnastics to call it +"free as in freedom." + +You should use JS anyway +------------------------ + +You're probably right, but if I use JS I won't be able to motivate +myself to write the damn code. Complex, poorly documented, constantly +shifting APIs directed at a completely different use case are not +exactly enjoyable to use. + +Use node.js. It has a sandbox +----------------------------- + +That's not a terrible idea, but I envision high concurrency and low +latency. Having separate processes that have to hang around even if +the code running in them is blocked on IO or sleeping doesn't scale +incredibly well. On the other hand, my approach will probably have +more security holes. I will probably at least have trusted and +untrusted Lua code running in separate processes in their own +namespaces and sandboxed with SECCOMP, but it seems likely that I will +have all untrusted Lua code sharing the same process sandbox, isolated +only by not having any mutable shared state. I don't yet know whether +that means separate Lua runtimes, however. That will require some +experimentation. + +Something is broken +------------------- + +This thing is nowhere near being in a releasable state. Please feel +free to report issues if you think there are fundamental design flaws +or you think I should change how something works, but don't expect it +to be actually useful for anything yet. So stuff like "you're doing +this wrong" is fine, but "I can't use this for X" is not.