Tuple Spaces for Human Interaction

Ever since my earlier days working in parallel computation, I had been fascinated by Tuple Spaces (aka Linda Spaces). I even had this opinion that you'll need to see Tuple Spaces adopted by the WebServices cartel before you could take it seriously. Well time has passed, even though you still can't take the WebServices concept seriously, I've changed my mind on Tuple Spaces.

Tuple Spaces main pitch is that its a coordination language that is orthogonal to a computational language. That is, you can append it to just about any language and you'll have a sufficiently useable framework to do distributed coordination. This decoupling has other benefits in that heterogeneous systems can coordinate furthermore since the mechanisms are general enough, developers need only to learn only one coordination language. In fact, the language is astonishingly simple, that is it contains just three operators: 'in', 'out' and 'read'.

Overtime, however I realized that its got one big drawback, that is, its more useful for machine to machine coordination than for human coordination. The Web is primarily a human interaction medium. Now if we went through the exercise of trying the match up the semantics with the semantics of the web we get into a little bit of a complication:

Is this RESTful? I dunno, you tell me. On the one hand, it's a much closer mapping to HTTP methods than tunneling everything through POST. The tuplespace-to-resource mapping is probably correct: a tuplespace is an encapsulation of a collection of tuples which exposes a simple but powerful interface, easily mapped to HTTP operations and semantics. OTOH, query strings worry me in general. But on yet another hand, it's clear that the "shape" of a tuplespace more resembles the "shape" of the parameter space of a query string, as opposed to the hierarchially mapped "shape" of the space described by a URI's path segment.

However, my concern with Tuple spaces is not with its query mechanism, rather my concern is with its pessimistic transactions. That is, I've written a lot about why pessimistic transactions aren't practical for the real world. Its my opinion that too make Tuple Spaces work in the grand scale of the web you've got to relax this constraint.

Fortunately, I've stumbled upon some guidance that I think might prove helpful. In research about adapting Tuple Spaces for interactive workspaces, I found a couple of prescriptions:

1. Self-describing Tuples: Since ensemble components aren’t necessarily designed to work together, it is important to have tuples be self-describing so users can figure out the intent of tuples by browsing through the tuplespace. This specifically means that every field has a name in addition to the standard type, and data.
2. Flexible Typing: In the standard model, the number of fields in a tuple and the order of fields is significant. For flexibly typed tuples, both field order and event size are ignored and matching is done by name instead. This allows applications to create extensions to standard event types that include extra information without breaking older applications. This is important since the collection of hardware and software in use is continually evolving.
3. Typed Tuples: In part as a side effect of using flexible typing, and in part because application writers won’t necessarily coordinate tuple structure, tuple fields with the same name will not always have the same semantic meaning. For example, ‘xPos’ may be a screen offset in one application and a position in a 3D model for another. This problem can be avoided by including in all tuples a ‘TupleType’ integer field which implies the presence of certain fields and the semantics of those fields. This provides a useful compromise between strong and weak typing. A problem still exists when application writers choose the same ‘TupleType’ value for tuples with dissimilar semantics, but having type greatly reduces the problem of name collision.
4. Tuple Sequencing: Traditionally, if multiple tuples exist that match the template tuple on a ‘read’ or ‘in’ operation, any of the matching tuples can be returned. Tuple sequencing means that receivers always get the earliest matching tuple they haven’t seen yet. Sequencing insures that applications requesting state change tuples will get tuples exactly once, and in order, rather than fetching the same tuple repeatedly. Since applications may sometimes want to peek at tuples, a ‘snoop’ method is needed to return copies of all matching tuples without effecting sequencing.
5. Expiration of Tuples: Since sources and receivers are decoupled, a source need not have a receiver to continue running. This may cause tuples to build up in the tuplespace, and for a real world system this means that the performance steadily decreases. To ameliorate this problem, all tuples should be given a ‘TimeToLive’ field that specifies how long they will persist in the tuplespace before being “garbage collected.” The expiration also facilitates human time-scale inter-application coordination by preventing action upon a submitted tuples long after the triggering occurrence. Thus, tuples should expire after a human would no longer expect the causal action to take place. For example, a light should turn on within a few seconds, or not at all—turning on hours or days later when some key component comes back on line but users have forgotten about the request is not acceptable.

Now, that's a little bit better than the original formulation, most of the prescriptions are affordances, that is mechanisms to make life easier. However, the prescription of tuple sequences changes the semantics at the core. In fact, the researchers have dubbed it "The Event Heap", that is:

In the Event Heap, therefore, tuples are called events. This reflects their intended use as a means of notifying other applications in the workspace of an occurrence, or of requesting that other applications update their state or perform some task, and emphasizes that the semantics are somewhat different than that of classic tuples.

In addition the 'out' and 'read' operators have been augmented with versions that are 'non-blocking'. The 'pessimistic transaction' constraint of the original Tuple space seems to have been relaxed to accommodate human interaction. Its nice to have a 'hunch' validated by serious research.

But hold your horses! I've got yet another 'hunch' that's just as equally interesting. "What if these tuples or events were versioned instead of just sequenced?"