[FoRK Classic] Manifesto: Cellular Programming

Date view Thread view Subject view Author view

From: Adam Rifkin (adam@KnowNow.com)
Date: Tue Oct 17 2000 - 13:11:37 PDT

This never got sent to FoRK-archive? Wow. Will have to change the
"1999" in the rant below to "2006". :)

(Rohit: recall that EDEN was my event notification work from late 1995 (!))

> From khare@pest.w3.org Sat Mar 16 22:21:03 1996
> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.1)
> To: FoRK-noarchive@xent.w3.org, kiniry@cs.umass.edu, connolly@w3.org
> Subject: Manifesto: Cellular Programming

> [Ed. In the beginning there was oSpace, then the oZone, then the
> "servlets of Eden". Courtesy of an accidental meme fertilization from
> Ernie, I'm now staking out virgin semantic territory under yet another
> moniker (ignore cellular automata and phone cloning for now...) ]

> [It should be noted that this kind of unrestrained technological
> fantasizing should be called 'geek porn' ;-]

> Far above the seven layer stack, the virtual machine, and the
> operating system, up beyond the clouds, is the object Zone. In the
> oZone, nothing is quite what it seems...

> [Prepare to dump spaghetti of loose ends]

> A Cell is the manifestation of some 'object' in the user's
> universe. It bears resemblance to an object: it has methods to access
> its state and control its behavior. It bears even more resemblance to
> a server (than to any existing object runtime or network runtime): a
> Cell is its own thread of control (i.e. only by messages, not by
> invocation -- see the E language).

> A Cell can manifest many interfaces (in the java/objC sense): it can
> appear to be an RTF widget, a number, or a color. Internally, a Cell
> might be a cluster of coherent corepresentations, or a single mighty
> program, or a single representation with symbiote transformers. These
> interfaces can have particular mutex policies and reliability
> ("optimistic answer NOW" and "correct answer")

> A Cell has a strictly defined border, and its own existence
> independent of the host or its users. It communicates via private
> messages (see E's capability sealers). It communicates only to types
> it was born knowing; others will have to be mediated.

> A Cell is a protected ecology within its borders. None may access the
> actual data (dna), only the methods expressed on its outer wall. A
> call across a cell interface is always asynchronous.

> A Cell logs all of its interesting transactions. Logs allow replicas
> to be reconciled, and the entire oZone to function reliably. Logs only
> get stabilized when a Cell makes promises to other Cells: you don't
> need to tell the truth until you tell someone else.

> Example Cells: [read 'oo file system']

> > An email message
> > A Calendar entry
> > A stock quote stream
> > A fighter in a Dist. Interactive Simulation
> > A news posting

> Or it could be a combination: an email message describing a meeting is
> both. Per Gelertner's ideas, anything that exists in the world or as
> a user's artifact deserves a Cell proxy in the noosphere.

> A Cell is not an Agent. It is not conscious, and most of all, it
> contains the data rather than the other way around.

> What operates on Cells? The nervous system of a local oZone (or the
> entire oZone) can detect interesting conditions and solve
> constraints. The oZone substrate offers services for locating,
> identifying, and messaging other cells. These are the key:
> 1. General naming: relative to the base oZone, and globally by choice
> 2. Distributed caching: automatic load balancing and storage
> 3. Inherent replication: any Cell can split and merge (implies
> persistence). [oZones can also implement 'subconcious replication' by
> actually simulating it on a fault-tolerant array of processors, like a
> majority-voting register]

> Underlying assumption: oZones spontaneously and intermittently connect and
> disconnect, and caching, naming, replication should deal with it.

> Basic Cells representing I/O and network systems are also part of the
> problem (stdlib)

> A Cell can divide. Unlike biological mitosis, which creates
> uncorrelated replicas (modulo shared dna), a replicated Cell may have
> a way to keep coherent state with its (possibly mobile, intermittent)
> peer. This is where the logging reconciliation comes into play.

> A Cell can move from host to host intact, iff we have secure
> coprocessors to protect the dna.

> Any Cell can fail. In the oZone, you gotta cope with failure. On the
> other hand, Cells can learn, since they have a seperate thread of
> control: what access patterns work, how optimistically to compute, and
> so on.

> Some Cells can express its interface in a myriad of ways: FORMs, vrml,
> over the phone, through a gameboy pad

> A Cell internally can be implemented in a myriad of ways: with a
> parallel language, multiple threads, etc. The value of this vision
> depends on a unified, multiple-VM substrate, though.

> A Cell is created by its Parent and endowed with a soul (a private
> key). It can only trust its creator, and is only known in the world
> relative to its creator. This is the only initial trust edge in the
> network. Ownership of an object can change, but its creator does not.

> From that starting point, a Cell gains new capabilities and identities
> only through a strict security system (the web of trust). The Cell
> only learns of the world piecemeal, too [thus, an oZone can reliably
> cull its connectedness to the rest of the universe].

> There is more to be said about this genealogical security model in
> some old notes of mine and Ernie's. Including an economic model:
> nanopayment should be assumed in the oZone.

> Cell logs can be aggregated and reconciled to allow multiscale culling
> of message traffic.

> The real win is in describing the design patterns of cellular
> programming. For example, the Calendar application:

> With EDEN alone, or ILU/HTTP-NG, or rmi, the developer has at most a
> persitency service, a name service, and a transaction service (EDEN
> tokens, CORBA xaction services). The developer has to write a meeting
> maker session from scratch, handling copies of events, and its own
> logging system for optimistic scheduling of disconnected users in an
> oZone, just hoist a new Event Cell into the space, and it will get
> knitted into the namespace of your other Events, and the other users
> within this Event. The oZone constraint logic rule for new events will
> alert other user's EventManagers as this Event becomes visible.

> Where do you want to be programming in 1999?

> Rohit Khare 3/17/96


Wait and see, time is all that we really need. -- Styx, "Don't Let It End"

Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Tue Oct 17 2000 - 13:16:06 PDT