Log as a Service (Part 2 of 2)

A few weeks ago, I started introducing Laasie, our new system for building powerful collaborative web applications.  We introduced the primitive interface for managing state -- state land.  This week, I'm going to provide a quick introduction to Laasie's more powerful abstraction for manipulating state -- log land.  

Log Land

Laasie represents application state not just in terms of its precise value at any given point in time, but also as a DAG of state changes.  Any DAG can be resolved (reified) into a concrete state by treating the DAG as a partial order, and evaluating the state updates in a compatible total order, starting with an initial "empty" state.  This particular representation of application state is quite powerful, as it allows us to access the full history of the application's state. We can track who made a change, when it was made, and what it depends on.  

More precisely, every time an update is written to Laasie, a new log entry is recorded for it.  Laasie then creates a set of pointers from the log entry to all log entries on which it depends, and can establish additional pointers if necessary (e.g., to an undo record, or to the last log entry for the value being modified).  The resulting set of log entries and pointers forms the Log DAG.

So what does the Log DAG buy us?  Well, it's a more powerful way of doing log analysis.  Typical graph properties such as (conditioned) reachability, isomorphism, cyclicity, and min-cut arise quite frequently when discussing optimal management of application state.  Using this simple abstraction allows us to create a single data management system capable of encoding a broad range of application-specific optimizations.

We're currently exploring analysis in log land using SparQL.  It turns out that a surprising number of properties can be mapped directly into SparQL with only a very small BarQL equivalent.  These include properties like reachability from the root (i.e., for garbage collection), commutativity, and recoverability (i.e., for operations like merges).  

We're on the verge of releasing an analysis tool for Laasie-generated logs, the first step towards both online and offline optimization of application state in Laasie.