Earlier today I was impressing my wife with some unix foo by automatically swapping FIRST LAST —> LAST, FIRST formatted data while sorting and finding duplicated entries (ok, so she was only mildly impressed). The shell command looked a little like this:
[lth@lappro ~] $ ./first_to_last.rb < new_names.txt | sort -f | uniq > back_to_you_bob.txt
Not rocket surgery, certainly, but still a great example of combining several small tools to achieve an end. This simple act re-filled me with awe on the beauty of design with lots of little processes. Processes enforce proper protocols and data hiding (unless you’re talking about cross process windows or some other such tomfoolery), they guarantee 100% resource reclamation, they afford a robust system where if one guy falls down the party can still pick up and continue.
But I’m like 2 years late here to this re-realization for the web: we already all understand the beauty of lots of little processes. The Chrome browser started by moving plugins (and just about every other distinct subtask) into it’s own process. IE8 joined the fray by running each tab in a separate process. Safari 4.0.3 on Snow Leopard running 64bit puts npapi plugins on the other side of a process break. The fine folks at mozilla are talking through it and will inevitably follow suit.
So this is awesome. Now our browsers don’t crash as much, instead they tell us “The Yahoo! BrowserPlus plugin has crashed” (for instance, usually it’s the Adobe Flash plugin, right?).. They tell us “the page is unresponsive”. Blame is appropriately assigned so we, as users, can complain to the right people. Fewer human hours are dwindled and more broken pages are fixed. Followed by an era of increased world peace and obesity. Great.
The File is the Thing
In that code snippet above, it’s really the file abstraction that deserves all the glory. Once we’ve got all these processes, how do they communicate? Well, first and foremost they need to be able to move data back and forth. The simplest way to do this is in an opaque blob. A file if you will. A container that is capable of holding data that can be moved back and for between loosely coupled components of the software system.
If you take a look at innovation on the web today, we’ve got plenty of separate processes, we’ve got HTML5 goodness running in browser, we’ve got Gears running in a combination of plugins and extensions, we’ve got BrowserPlus running in an NPAPI plugin (or activex, but they always have thought different), we’ve got adobe flash in another plugin, and if you’re retro there’s a little java soup in there too (right, Silverlight too, don’t forget! this is important!).
Now in most cases, all of these runtimes/tools are running in different processes. And we have two choices: first they could be extremely loosely coupled and only share a control channel that’s brokered by the browser (as the world is today), or they could be more deeply integrated. It could be possible to build a web application using multiple client technologies that pass data back and forth. Imagine using HTML5 drag and drop to attain file handles, passing those into, say, BrowserPlus to process or alter the file contents, then taking the result and uploading it peer to peer using, say flash?
A simple file abstraction shared by all of these platforms is the key to interoperability.
Why do we care?
Why do we care if the interoperate? Simply because we need to nurture experiementation, and if there is no clean way for extensions to hook into browser supported drag and drop, then we’ll see monstrous hacks arise to make them interoperate so that non browser companies can continue participating in the innovation (without building yet another browser, so yesterday).
HTML5 and the File
Some very cool happs are goin on over at the w3c regarding files, uploading, and drag and drop. Excellent work in a pretty package.
The One (File) Two (Stream) Punch
So is every browser going to implement powerful client-side movie editing? Or is this a bit bigger than what we want to build in the browser? Let’s assume I can name a feature, X, that’s interesting in a browser, but more than we could ever expect microsoft, google, apple, mozilla, and opera to go and implement. The web is the platform, right? We still want to be able to build this in open web technologies (uh, the user drops the movie on the page).
I suggest a simple fix on the npapi side. Here’s the patch:
Next we can talk about streams, which buy us an efficient way to build a playground where everyone’s workin' together.
simple, yeah? lloyd