[erlang-questions] "actor database" - architectural strategy question

[Miles Fidelman]

Hi Richard,

Richard A. O'Keefe wrote:
> On 18/02/2014, at 12:22 PM, Miles Fidelman wrote:
>> Ok.  After reading what others have said about garbage collection, this is clearly issue number one that I'll need to address.

Well, you're taking that a bit out of context - I was responding to 
this, along with some other comments about various garbage collection 
issues:

<Joe Armstrong wrote>
> Some kind of "getting things out of memory and onto disk when not 
> needed" layer is needed for your problem,
>
<I responded>
> Ok.  After reading what others have said about garbage collection, 
> this is clearly issue number one that I'll need to address.
>
> At first glance, it strikes me that the hibernate BIF does at least 
> part of what's needed - any thoughts/suggestions as to whether it 
> might make sense to approach this by extending hibernate, vs. 
> something at the application layer?  And, if it makes sense to play 
> with the BIF, any quick pointers to where I might find detailed 
> documentation on how it's implemented? 

Referring to "getting things out of memory and onto disk when not 
needed" rather than garbage collection.

But... in response to your comments

> I think that issues 0, 1, and 2 are
>
>   0. With a distributed replicated collection of active
>      documents, how are you going to correct errors without
>      the system correcting them back?  (This leads to
>      questions of authentication and control.)

For the collaborative document applications, it's not clear that that 
correcting errors is necessary.  It's more a version control issue.

I'm thinking more of a document as akin to a program under version 
control - complete with branches, merges, tags, .... - I make some 
edits, someone else makes some edits, the changes propagate as messages 
- branching occurs.  One can browse through different versions, change 
sets, etc.  One can also define "releases" (e.g., the one that goes to 
press.)

Add business rules that are document specific - such as who is allowed 
to generate a "define version" message - and one has a document 
management process for a specific replicated document.

>
>   1. With a distributed set of *active* "documents",
>      what stops divergent computations?
>      (E.g., document X is created, then document Y is created
>      with a rule "I am document X plus the letter Y" and then
>      document X is revised to "I am document Y plus the letter X",
>      and it's "To infinity and beyondYXYXYXYXYXYXYXYXYX..." time.)
>
>   2. Versioning and metadata.
>
> I think distributed GC can/should exploit versioning and metadata
> and must respect authentication and control.

Exactly!

>
> But that's just my NZD 0.01.
Great minds think alike :-)

Cheers,

Miles

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra