© Kevin Mehall and the Splash Contributors
The motivations behind the Splash Project
By Kevin Mehall
In the past 25 years, little has changed in the design of consumer-oriented software systems. Today's operating systems still feel similar to the UI of the original Mac in 1984. The design compromises made in the 1980s were justifiable at the time, but the computer hardware and the ways people use computers have changed. Computers are becoming increasingly important in peoples' lives. The power of computers has exponentially grown, and the Internet has connected them, allowing for possibilities unimaginable when the designs were set in stone. These haven't changed because developers are lazy, declaring the status quo to be "good enough", and not questioning further. The goal of the Splash Projects is to reverse the stagnation by designing and implementing a fully modern computer system that is secure, reliable, and easy to use.
Users of current operating systems primarily interact with applications. Each application seems like a walled garden, only interacting with other applications through the filesystem and the clumsy and unreliable drag-and-drop / clipboard. This isolation makes it more difficult for users and programmers alike. Why can't a user edit a photo embedded in a document without exporting it to a file, editing it, saving it, and importing it again? Why can't a developer of a web browser embed a text editor widget that already has basic but currently missing features like spellcheck and find/replace? Why can't a user keep one address book that works for e-mail, IM, and syncs to their phone contact list? We see developers re-implementing the same functionality over and over again, wasting effort and duplicating code. The users are left to constantly convert between formats and learn several ways to accomplish the same task.
The UNIX (and by extension, all other current operating systems) philosophy is stated as "Everything is a stream of bytes". Wrong! Users don't care about bytes. Their data could be stored as stone carvings in a cave on the far side of the moon if that was reliable and accessed quickly. Yes, everything in Splash is stored as bytes at some level (A stone-carving back-end is under development; rocket not included), but Splash itself provides structure on top, something that programmers currently have to implement themselves. Splash takes care of data serialization, taking advantage of the fact that all objects can be stored the same way. Splash stores all data in a transparent, universal format.
Instead of applications and files, Splash has objects. They work similarly to the objects familiar to programmers working with object-oriented languages, but are system-wide and much more flexible. An object is simply a chunk of structured data with an attached type. The data in an object consists predominantly of references to other objects. This structure makes the Splash environment much more open. Unlike files, which are opaque blobs that can only be opened with certain programs, the fields of an object can be directly inspected if necessary, and accessed in code more easily.
Why must the user manually save things at all? The all-too-common "Would you like to save this file before exiting?" should be re-phrased as "Would you like to throw away the work you just spent valuable time on?". With storage as cheap as it is today, Splash transparently saves all data automatically as it is created. Unwanted objects can be explicitly deleted. Objects can be versioned, creating an undo history that goes all the way back to the creation of the object. Together, the auto-save and versioning mechanisms eliminate data loss.
Current GUIs are a separate layer built on top of the underlying data model. In Splash, the data objects themselves are presented to the user. Code specific to an object type can customize the display of an object. The same actions used by programmers are exposed in the menus of the GUI. A user clicking a menu item is the same as a method call on an object. This means that the interface only has to be created once, instead of separate API and GUI. Of course, human-readable names are used, and extensive help is provided to make the actions accessible to average users. Scripting is also easy, since the user is already familiar with the actions that can be used in code.
Computer code is not plain text. So why is it stored that way? The fact that code has structure that computers can understand is what makes programming possible. Splash stores code as structured data (an abstract syntax tree), providing great flexibility in what can be done with it. No longer is the syntax the defining attribute of the programming language; the code can be viewed and edited in any way the user chooses. Some people may prefer C's curly braces, some may prefer Python's significant whitespace, and some may prefer Lisp's S-expressions. They can all have the syntax their preferred way. The IDE is also aware of the structure of the code, and can therefore be more helpful to the programmer. This also opens up many possibilities with graphical representations of the code.
As every user knows well, today's computer systems are horribly insecure. A fundamentally flawed approach is taken: Systems are built insecure from the start, and patches later try to plug the holes. This simply doesn't work. Antivirus and Firewall applications are examples of these patches. Why do you need a firewall if ports are closed by default? Why do you need antivirus if code running on the system cannot touch anything to which it is not explicitly given access.
Splash uses Capability-based security. A capability is like a key that uniquely identifies an object and names a set of operations that can be done to it. Since all objects are accessed through capabilities, code can only access a small number of objects whose capabilities it has been given. Contrast that to existing operating systems, where programs have the full access privileges of the user. It cannot be assumed that the user completely trusts every line of code they run. Malicious code in Splash wouldn't hold any capabilities and therefore couldn't access other objects.
Applications are responsible for serializing their data and writing it to files. Much effort is duplicated, since most applications have to save data in some form. Since Splash objects are all in a common format, Splash itself takes care of saving and loading data, and does so transparently.
Resource management is currently the task of the application programmer, if not left to the end user. Users have to keep track of memory usage, and close programs to keep the computer from running out. In Splash, this is completely transparent. It knows when memory is running low, and flushes objects that haven't been touched for awhile to disk. When they are requested, they are loaded again. It almost works like using the entire hard drive as a persistent swap file.
Network transparency is also important in this increasingly-connected world. Currently there is a huge gap between the local machine and the network; users have to manually upload and download files. Splash again does this transparently. Capabilities can point to objects on other computers, and they are located and accessed when necessary. It determines whether to download the object or convert access into remote procedure calls. Caching is handled automatically, and at a system-wide level for maximum efficiency.