J5’s Blog

Introducing Jester. Jester is a JavaScript unit tester based around GNOME’s Gjs JavaScript engine. I wrote it because I needed a stand alone tester for testing non-DOM JavaScript code in my AMQP Bindings (kamaloka-js). I also wanted to learn the ins and outs of Gjs and GLib Introspection while making it relevant to my friends in the GNOME Community. By utilizing a separate run time for non-DOM code I hope to encourage the separation of browser and generic JavaScript code for the sake of reuse across browser and desktop platforms.

Jester has a couple of components and can be used indirectly or directly by Gjs applications. The first component is the jester standalone application which can load and run a JavaScript file from the command line. Use this to integrate with test workflows such as make check or to simply test out some quick JavaScript. The second component is the jester.js module which can be loaded directly in a Gjs application. This module contains the Test class which is used to write unit tests.

Here is a simple example of how to use Jester:

test.js

const Jester = imports.jester;

let test = {
    testExample: function() {
        this.assertEquals(1, 1, "This test should always pass");
        this.assertEquals(1, 2, "This test should fail");
    }
}

this.info("Jester Example");
let test_suite = new Jester.Test({"Simple Test": test});
test_suite.run();

To run this code you would enter this on the command line:

jester test.js

Home Page: http://live.gnome.org/Jester
0.1 Tarball: http://live.gnome.org/Jester?action=AttachFile&do=view&target=jester-0.1.tar.bz2
Git:

• anonymous – git://git.gnome.org/jester
• commit access – ssh://USERNAME@git.gnome.org/git/jester

Since kamaloka-js is built on top of js.io, I have create a patch for js.io which makes the importer work when used with Jester.

I am proud to announce version 0.1.0 of the kamaloka-js AMQP bindings. This initial release is considered to be an alpha quality release. It is there for you to break and give feedback so we can continue to improve the bindings and eventually get them to the point where they can be used to run mission critical applications.

In the next few days I will be concentrating on documenting the design of the bindings so anyone who wants to can easily jump in and contribute patches as well as suggestions. Please visit the project page to find out more and see how you can help out.

What’s in store for the future?

• High level bindings for each of the major AMQP client patterns to get developers up and running with AMQP in the browser fast
• QMF bindings for working with the QMF management console

Where can I find this release?

• kamaloka-js-0.1.0.tar.bz2 (sha1)
• kamaloka-js-0.1.0.zip (sha1)

What’s in this release?

• Initial release
• Connection handshaking works
• AMQP lowlevel bindings for version 0.10 of the AMQP Protocol mostly complete
• Higher level bindings implementing the publisher/subscriber pattern is ready for use

How can I find out more?

• Project page: https://fedorahosted.org/kamaloka-js
• FAQ: https://fedorahosted.org/kamaloka-js/wiki/Faq
• Mailing list: https://fedorahosted.org/mailman/listinfo/kamaloka-js-devel

Kamaloka-js is an implementation of the AMQP messaging protocol (http://amqp.org/) in native JavaScript released under the MIT license. It is setup to be used with Orbited (http://orbited.org/) but can be used with any library which produce TCPSockets in the browser similar to Orbited. Kamaloka bindings are generated from qpid XML protocol description files.

While I am developing on Firefox today I tested and fixed some issues under Chromium (webkit based), Opera (opera based) and Konquorer (khtml based). My pub/sub demo worked the same in all four browsers (and at the same time I might add). We tried with IE8 on Luke’s machine but the error messages were cryptic. I’ll have to get my hands on a windows box at some point but I’m guessing the biggest issues are going to be trailing commas or keywords which are similar in the amqp spec and javascript (e.g. I ran into void and class keyword issues with the webkit browsers).

One thing to note is Chromium’s integrated debugger is a lot faster than Firebug. I haven’t used it extensively but if it can break at breakpoints and introspect objects without getting screwy I might end up switching. I really like firebug but lately it has become dog slow. It usually takes a couple of minutes of waiting for each frame of data to be processed and displayed while under Chromium with their debugger on, the slowdown is noticeable but not significant compared to when the debugger is off.

UPDATE: Chromium’s debugger is probably faster because it doesn’t actually do anything that I can see. It displays scripts but doesn’t actually break into the code

I managed to make it home in one piece from Vegas and dove right back into work. After getting away from messaging for a bit I have come full circle but with a little bit of a twist. In an effort to bring some of the goodness that is interprocess messaging to the interwebs – similar to what we get on the desktop with D-Bus – I am implementing the standard AMQP protocol in native JavaScript.

This along with QMF will give us the ability to send out notifications of events, monitor statistics and eventually supplement REST and XML-RPC interfaces with more efficient multi-response method calling (imagine streaming rows of data instead of waiting for the entire row set to be sent).

AMQP Handshake over Orbited

Above is a little hex dump web app I wrote to test the bindings. What you see is the start of the AMQP handshake. First I send the header indicating the version of the protocol I am expecting. I then get the ’start’ response back stating the capabilities of the broker I have connected to. I then send the ’start-ok’ packet indicating what auth mechanisms I support and the locale (I would also send a token if I were using a particular auth other than anonymous).

That is about as far as I have gotten but since the bindings are autogenerated from an XML description of the protocol most of the control and command classes are implemented. There are still some types I am trying to figure out how to support (the supported types are a magnitude above what was needed for D-Bus) and I need to smooth out the rough edges as well as write the higher level user bindings but I am off to a good start.

Code will be posted as soon as the project resources are approved and setup. Keep watching my blog for updates.

BTW: The slow response times in the time stamps are due to running inside of the firebug debugger and writing out the hex dumps on the fly using JQuery. It seems the more sophisticated JQuery and Firebug get, the more they butt heads.