Re: The Fight

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.

So I tried to think about the web from the perspective of an application platform. Having built what we have, what could we do differently if we could do it from scratch? Clearly, security is one of the biggest problems. It is a problem with existing applications, but many of those security holes can be protected against with effort. The even harder security problems are the ones that have no solution. The kind that are attempting to be solved by Google Gears. Mashups have become a popular idea that cannot meet their true potential due to insecure connections between domains/owners/code bases.

In a recent presentation by Douglas Crockford, he talks about moving the web forward. There is a lot of great stuff here. There always is. But there are two major things that I wanted to address.

1. “The next great leap [in software] might realize the dream of assembling software like Lego.” He further stated that that leap was being realized already through Mashups.
2. Mr. Crockford goes on to describe how the current web technologies (both open AND closed) are far too insecure for anything but the most trivial Mashups. He then lays out how the web can move forward:
   • Safe JavaScript subsets (Caja, Cajita, ADsafe)
   • Communicating Vats (Gears)
   • Secure Programming Language (?????)

Interestingly enough, I recently saw something on InfoQ about “Lego” software in a presentation called, “The Lego Hypothesis” by James Noble. His presentation is worth a listen, but it is long and rambling and a little hard to summarize as easily as Douglas Crockford’s. However, the subject matter was relative. He discusses the history and feasibility of the dream of Lego block software. The same concept as described by Crockford in his presentation that he believes will be the “next great leap”. Noble demonstrated the complication in the Lego dream. Mostly that it’s a lot more complicated than plugging different parts together. You cannot build a complete application out of simple reusable parts. Some things have far too many dependencies to be simply abstracted into a reusable plug interface. In contemporary programming the best we can hope for is to glue together what we can to reuse.  Near the end of the presentation, he did in fact point out how Mashups have the right idea and that more and more software will go in that direction.

I agree with Crockford and Noble. The fact is that modern software and the web are fully intertwined. There is no going back to the dark ages of isolated machines. It’s not just about RIA anymore. And the fact is, as we move more and more towards networked information, we will need the ability to integrate between parties that have to operate under mutual suspicion. Crockfords third point about how the web can move forward has some question marks next to it, but I hope that Spindle can be a possible solution. A language with the goals of secure distributed computing.

I know I keep putting this off. I started this post with the intent of actually describing Spindle, but I guess it’ll have to wait till next time.

Things just keep getting better. What can I say. A lot of the fear I had about the open web shriveling up an dying has been all for naught. The Open Web Foundation is pushing to keep ideas and technology open, Google has thrown in their hat with Chrome, and Harmony has spread across the web. yay. Heck, there’s even an Open Web Podcast doing a much better job than me in keeping an accurate post of what’s going on.

But enough of all that! This meaningless blog was never about that stuff. It’s about my practically non-existent pursuit of building the next generation of web technology. I just wrote this post to say that I think we’re moving away from the fears that haunted me in the night. However, I think my gripes about HTML5 are still pretty valid. I’ve been watching the mailing list a lot and I really do think they’re making great progress. What with the video tag and the inter-document communication and all that other crap. I think it’s going to make a lot of people happy. Including me. I just don’t think it’s enough. But I said that already.

Sooo… I’m gonna start talking about what I’VE been doing lately in my tiny tiny tiny amount of free time. At the moment, it’s called Spindle, and it’s a programming language that I’m designing to better handle the problem space of the web and the untapped potential of distributed computing.