syntropy/webreduce — Issue #2: Persistent Objects
Author: surma
Created: 2012-01-09 12:58:30+00:00
State: open

## Problem
I know, we’ve been over this; persistent objects are in conflict with pure continuations etc yadda yadda.
**BUT**: Our current approach is actually *less* powerful than our previous map/reduce-based design because right now it is impossible to do any kind of data reduction (think *joins*). The only way to join data is to add an external behaviour. Since reduction is a fairly common process it would be rather stupid to force adding a connection to a remote server to be able to do reduce data.

## Proposal
Every behaviour has access to its own personal, persistent object. Manipulation occurs via an API (this is JS specific, but can easily be ported t other potential interpreters):

```JS
window.WebReduce = {
// Returns the current persistent object
getPersistentObject = function() {
// native
return obj;
},

// Sets of the persistent object
setPersistentObject = function(obj) {
// native
},

// Deep-merges `obj` into the persistent object
mergePersistentObject = function(obj) {
// native
}
};
```

I imagine the `mergePersistentObject` to be particularily useful to avoid race conditions later on.

As a consequence, though, we’d have to have some kind of mechanism to synchronize said persistent object among an arbitrary number of servers – although I guess one central [MongoDB](http://www.mongodb.org/) might do the trick.