Technical overview

While I'm going to focus on Lua and Javascript to avoid too much fragmentation, a goal in this project is to eventually support a wide plethora of languages as handlers. Perhaps someday even stuff like NaCL, although Lua's surprising speed heads that need off for awhile.

A handler is a resource in a DEJE document that deals with events and can access other resources. Generally, these will be languages that work well in sandboxed interpreters. The default handler locations are:

• /handler
• /handler.lua
• /handler.js

The document has a "_handler" property that contains the path to the document's handler resource. So, generally, mydocument._handler will be one of those three options. This can be changed with document.set_handler(). You can quickly grab the handler resource with document.handler.

The interpreter is chosen based on the resource type, never the filename, never guessed based on magic numbers or hashbangs or similar complex voodoo. Simple is saner than automagic. If document.handler.type is 'text/javascript', the V8 interpreter will be used. If 'text/lua', then the Lua interpreter will be used. At the time of this writing, only the Lua interpreter works, and it does not have any security features.

Your handler will have a limited set of globals to work with, dependent on language. This is intended to minimize the attack surface, which is an important concern when running untrusted scripts. This includes

The handler will run every time time a document is "activated." Activation is decoupled from document initialization for efficiency, so as not to spin up an interpreter until it's actually needed. Activation is done for you automatically when events happen, so that the handler will be available to handle them. Your interpreter may be deallocated at any time without warning, so the only storage you can really count on are resources and scratchspace, which are available through the API.

Handler API

---

v0.0.2