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?
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 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:
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.