Joseph Spiros

Haven consists of a daemon (referred to as havend) and a library for communicating with that daemon (referred to as libhaven). Individual computers will run a single instance of havend, and any other software (referred to as client software) running on those computers which requires access to the database utilizes the libhaven library to communicate with the local instance of havend. read more »

At the lowest level, Haven utilizes a document-oriented, schema-less database. I’ll use the term “object” where other systems would use “document”, to avoid connotations of “document” that are not appropriate at such a low level. Objects have a UUID to define their identity, and an arbitrary number of key/value pairs as content. Key names are informally standardized using reverse-DNS semantics. All objects, once assigned a UUID, are immutable. The immutability of objects referenced by a given UUID allows for the Haven database to be distributed over many, perhaps distant, computers. Ideally, there is only one Haven database (or, object namespace) for all eternity. read more »

I often find myself thinking about how the next great computing environment should function. Although computer hardware has advanced considerably over time, the user-oriented software that allows us access to that hardware’s potential has been stuck. We’re constantly rehashing the same tired metaphors that were developed decades ago: keyboards, mice, windows, icons, files, applications, clients, servers, users, passwords, and so on. A little more than a year ago, I started thinking about how the computers of the future should store and access data. After much refactoring of my ideas and their consequences, I have settled on a system that I call Haven, which I will be describing in this and later posts. This first post will talk about the sorts of problems that I have attempted to solve. read more »