[cap-talk] How desirable / feasible is a persistent OCAP language?

[Toby Murray]

On Tue, 2008-07-22 at 19:38
> Rephrasing what I posted previously:  Persistence is
> hard, and is apt to get you into trouble when one needs
> to update and change what is persistent.  Object
> capabilities become interesting and important on
> distributed systems, on networks, and distributed update
> is an enormous problem, not yet fully understood.  When
> complications due to persistence intertwine with
> complications due to distributed data and distributed
> update, we get in really deep trouble.

Could you elaborate further on the problem of distributed update? What
exactly is it and how does it arise in practice in current distributed
systems?

Is it essentially a problem of coherency -- i.e. ensuring that the local
representation of a remote object is consistent with the current state
of the remote object, and vice versa?

This problem is often helped by never assuming synchronous access to
remote data, which is what most distributed object-capability
implementations do, by allowing only asynchronous distributed
invocation.

In a system, like E, that supports only asynchronous remote invocation,
could you give an example of how the distributed update problem could
interact with E's support for persistence, in which objects in a single
vat can be revived from an on-disk representation when the vat is
restarted?

This would help put things into a much clearer context. I'm having
trouble understanding what the problems are at the moment.

Cheers

Toby