Spindle

So I looked at Mashups, and I looked at my own personal gripes about application development on the web, and I started trying to find a solution. I began at the language level, because that is the level at which I work (as a programmer), and also the level at which I think.

The problem space of creating a nice application development platform is one with a lot of answers. The problem of securely distributed computing with untrusted sources less so. So that’s the part I’m approaching first.

Erlang, Gears, Isolation

Mashups are happening on the web now (not securely) and Gears is an attempt to fix, but let’s be realistic. We cannot keep putting band-aids on this. (Well. We can. I just hope we don’t.) Without straying too far from what has made it successful on the web, what else is out there to see what works?

Erlang comes to mind. (I know I’ve said this stuff before in previous posts, but I thought it would be good to refresh). The message passing model works well for concurrency, but also for security. Both are going to be important for us. There is no way to avoid concurrency in a system built for network communications. The internet is one fat concurrency issue. The single threaded JavaScript model doesn’t work, and asynchronous callbacks are clumsy. Additionally, isolating processes with no shared state and a message passing model is a great way to keep untrusted sources from wreaking havoc.  The smart people at Google recognized this and created Gears workers. The question you may be asking is, “Well if Gears does this, why do we need a whole new language?” I’ll tell you. JavaScript was never built to use a message passing model. Using strings to pass messages around sucks. The lack of message pattern matching is a pain. It still doesn’t solve the major problem of accessing the dom. And asynchronous callbacks are still clumsy.

So let’s say we put Erlang in the browser. Would that actually work? Doubtful. Erlang unmodified has plenty of it’s own problems, or rather, it has some design choices that would not work well for the browser. For one thing, it’s strict immutability and almost purely functional syntax would not fly in the general public. For another, it just has no concept of a sandbox. It’s all or nothing.

The Sandbox

Many languages have implementations that operate in a sandbox. Java prides itself on sandboxing. It has those marvelous confirmation dialogs. JavaScript is also sandboxed. In both of these cases the sandboxing is really only protecting the user and the system from the program. What both of them lack is a way of protecting one part of the program from another part of the program.

The first concept when conceiving of Spindle was that it must have the fundamental concept of a sandbox. A barrier protecting one part of an application from another. A sandbox is more than a process. A sandbox is basically defined as the place where code lives. No code is shared between sandboxes. A function in one sandbox is not available in the other unless it is explicitly loaded in that one as well. It goes without saying that they do not share state. A sandbox can spawn one or more lightweight processes to actually execute code. These processes share a code base. This way code does not have to be loaded in duplicate into each process. The only communication between sandboxes is through messaging. In this way, it is the same as between processes.

Breaking up data from behavior

So I was thinking about this message thing. I thought about my own experience passing json between client and server. Luckily for my team, we built a system from automatically marshalling and unmarshalling so we never dealt with the raw json. It seemed to me that if messages were basically json objects, that should be built in for free.

So I thought that it might be a good idea to clearly divide the data from the behavior. An object has certain “properties”. When turned into message format, these properties become the data structure a la json. When accepting a message object, it should be just as easy to flip it back.

Imagine you send a Person object from one sandbox to another.  Or even from server to client. Using json notation, lets say it just looks like:

 {"firstName":"Russell", "lastName":"Leggett"}

But you actually have a Person class (or prototype) with some functions. Instead of having to create a new Person object and transfer the data, it would be nice to be able to ‘imbue’ the object with Person functionality. Like so:
personVar <- Person

Now this might seem like something as simple as copying functions over like many utilities do, but there’s more to it. It would be more like swapping out the prototype on the fly.

This thought process brought me around to the idea that the specification for functions should stay away from properties. This breaks the fundamental concept of prototypes, but hey, I’m not trying to build JS2.

Those were my main initial thoughts going into Spindle. There are a lot more ideas I’ve come up with since that starting point, and I’ll get to those next.