1. mschwartz
    I recently started on a new SSJS project, a WWW server I call Silk.

    I'm only 2 days into it so far, but it's coming along quite nicely...

    It's a pre-fork model WWW server written in C++ for Linux. Each HTTP child process shares a SpiderMonkey (Firefox JavaScript engine) runtime and runs a JavaScript in a process private Context.

    It's really a simple thing, sort of like NodeJS. From the command line, you run it like:

    silk [-c number_of_children] [-p port] path_to_javascript.js [arg1 arg2 ...]

    It loads "path_to_javascript.js" and runs it for each request. The script is passed the optional arguments (arg1, arg2, etc.).

    The server creates a global object for the script and places a res (global.res) and a req (global.req) object.

    The req object contains the HTTP headers, method (e.g. GET, POST), the URI, IP address of the browser, etc. It will soon also contain the equivalent of $_REQUEST[] (PHP) variables and cookies.

    The res object currently only has one function: write(s) - which writes a string to the browser. It will soon have response headers and cookies and a few other functions. One obvious function is res.forward(path, mimeType) which sends a file to the browser; the file could be an HTML document, a JavaScript, an image, etc. The JavaScript determines the mime type. The res object will also have functions to set cookies, set the HTTP response status code, add headers, etc.

    My TODO list is amazingly short:
    1) File uploads
    2) Glue for Posix (e.g. core Linux functions: files, sockets, etc.)
    3) Glue for MySQL
    4) Keep-alive requests (this is a trivial bit of coding)
    5) Implement include() and require() (commonJS style)
    6) Optimize by precompiling scripts
    7) Gzip output compression
    8) Shared memory between chlidren/scripts.
    9) Built-in cron

    Without any real optimizations, the HTTP child processes do a lot of work. They create a SpiderMonkey Context, create the global object, stuff req/res objects into the global object, and does an eval() (basically) on the script.

    Yet, when I run Apache Benchmark (ab) against Silk and against Apache, Silk is 10% faster. And Silk is (evaluating, etc.) executing a JavaScript while Apache is just sending its "It works!" flat HTML page.

    Clearly Silk can be used to implement full blown WWW applications (include/require!).

    Yet as a tiny and fast WWW server (res.forward), you can implement whatever rules you want with a few lines of JavaScript. For example, your script can serve images (res.forward) but only if HTTP_REFERRER is your host (e.g. prevent bandwidth leaching!). Your script can do virtual hosts - the URI is in the req object, just parse the hostname and do whatever you want based on that.

    I'm not entirely sure what I'm going to do with Silk when I get it to alpha or beta stage. More to come.
  2. Frank
Results 1 to 2 of 2