JSONOID hacking

I hid myself away this weekend (modulo a late night Halo session with Rob, Ben, Kurtis, Andy, and Kwaaang) for some Rhino hacking. Now I have a JavaScript environment that can execute batch files or act as a shell, and most importantly, let you snapshot objects of interest:

$cat test.js
group1 = JSONOID.makeKey(); //recording group for associated items
function foo (x) { JSONOID.record(group1, x); }; //record something
foo(1); foo(2); foo(['a', 'b', 'c']);

$java -jar JSONOID.jar test.js
%%location 1
XP
v 1 "number"
%%location 1
XP
v 1 "number"
%%location 1
XP
v 1 "array"
v 2 "string"
v 3 "string"
v 4 "string"
e 1 2 "0"
e 1 3 "1"
e 1 4 "2"

I handle cyclic references and flatten prototype chains (so you see inherited edges, but they aren't labeled as being such). I haven't tested function wrapping support yet, but that's library level mostly.

Next step is to do some machine learning awesomeness and integrate it with Flapjax. The former just got a bit annoying because the package I wanted to use crashes when I try to use recursive features (which is pretty key to what I want to do). The latter part is interesting: Rhino is pure ~JS1.7, while a significant portion of Flapjax is about using the DOM safely and cleanly. Luckily, John Resig hacked up a browser environment emulator - in JavaScript - that I can just load in! Problem solved.

Resig's blog post in which I found the library was in relation to an interesting topic: JavaScript on the server. I predicted a few things a couple of years ago with Lee and Jono: a gesture based mp3 player phone with no buttons (too bad that doesn't get me a free iPhone!), and JS on the server. The latter was in multiple contexts so I don't feel as neat about it: security (emulate / check client code before running it), server scripting, and integrated languages. The last part doesn't make as much sense just yet, but next semester will be spent focused on an efficiency part of that equation, and it looks like Steve Yegge's NBL is ES4 and he's approaching the usability side of things with a Rails solution for it. I think that's a short term solution for building big, performant, analyzable apps, but I agree that it's probably the fastest way to go for now.

One piece of sadness: apparently CouchDB is really, really slow. Michael did an afternoon of hacking and outperformed it by a magnitude or two with a very ad-hoc solution using BerkeleyDB. However, the basic concept stands. We'll see what I want to hook Flapjax up to.