On Thu, Jun 30, 2011 at 3:13 AM, Chris Warburton <[email protected]>wrote:
> On Wed, 2011-06-29 at 11:40 -0700, Alan Kay wrote: > > The only human artifact that is remotely like this is the Internet, which > has > > been able to grow and replace most parts large and small without having > to ever > > be stopped. > > At the network level we have the Internet, as an 'Intergalactic > Network', but it is never interacted with directly. Instead it has > become, in the developed world at least, a ubiquitous communication > medium *for our devices*. > > At the software level we have, for example, Smalltalk. As has been > mentioned many times before, this is essentially its own network of > pluggable computers (objects). The internet is made up of active objects with a high level of concurrency. If you're searching for analogous software models, don't look to Smalltalk with its passive objects and control flow. Multi agent systems are a better comparison. We want resilient, scalable, open applications. Consistency, security, graceful degradation, and behavior during and after partial failures (disruption, partitioning, node failure, buggy software components) will be major concerns. Our models for communication, concurrency control, identification and linking of dependencies, system discovery, and configuration management are all impacted. To be 'eternal', we need runtime upgrade - the ability to upgrade and modify software components without restarting the whole system. We desire 'live programming' - ability to upgrade and modify a component without disrupting active users. If a developer must know the entire history of an eternal program in order to understand its current behavior, that would be a serious obstacle to long term development. So, after upgrade, the modified system should quickly reach a state as though it were always using the new code. This has a profound impact on the use of 'state', and suggests favoring a reactive programming model that can easily propagate a change. Our data models will change over time... but the data models of our dependencies will change at their own pace. This suggests that we need effective adapters between data models, such that we can transparently replace a model with a 'view' of it. I think the distinction between model and view breaks down very quickly. I've been developing requirements, desiderata, and programming models for open distributed systems programming since 2003, with an emphasis on real-time systems. The resilience and upgrade requirements for open distributed systems naturally imply eternal computing. In April 2010, I finally came up with a model I find extremely promising (though I've only run it through pseudocode tests). I call it 'Reactive Demand Programming'. I started to blog the subject in May 2011 [1]. > These are the ideal wearable computer, as they are perfectly acceptable standalone machines wherever we are, but when we sit at a desk they merge with our office computer seamlessly so that we don't have to care about eg. sync issues. I'm also interested in 'pervasive' computing, augmented reality. For example, consider the ability to take a picture of a printer then drag and drop a symbol for a document onto it. This would require we identify the printer by some combination of its image and other indicators for our location. You might check out a language called 'Ambient Talk', designed to support mobile computing and interaction with the environment. Unfortunately, Ambient Talk is not designed for security My favored model for 'discovery' of the environment and dependencies involves a network of fine-grained, composable, RDP registries (i.e. a network of micro-databases). Each can be administered separately, adjusting the filters and such, and there are separate publish and query capabilities. The registries are stateless (in RDP, I can replace most state with 'continuous publish', and simply make disruption equivalent to revocation). Different registries can represent 'ambient' vs. 'machine local' vs. 'global' resources (and, appropriately, different levels of security). Individual users and organizations will tend to maintain their own registries. > > Every once in a while we would prune off the dead parts from our > computers (while the working parts are still running, uninterrupted), > buy a pack of fresh computer and stick it on. Even if we had easily replaceable computing substance, we should still expect disruptions. For example, the dead computing element might be the bit handling the camera or display. In 2007, I came up with an idea of declaring dependencies between components in order to control partial failure: i.e. the creator of A can declare 'A depends on B'. If B is ever disrupted from A's perspective, then A also becomes disrupted (drops all communications). If B is ever destroyed permanently, then A can be destroyed permanently. The idea is to propagate partial failure to boundaries where developers can more effectively recognize and handle it. Fallback services or regeneration protocols can be introduced at those boundaries. This gives us clean failover. Declarative dependencies can be combined with 'suicide' components (which die on command) to securely prune old software from a system - i.e. manual memory management, job control, etc. except controlled by capability security. One advantage of these declarative dependencies is that we can derive from them precisely how much redundancy we actually need in our software, while recognizing valid sources of disruption. For example, if software component B has a dependency on camera C, then there is little reason to have redundancy of B that will survive destruction of C. I developed this idea for a variation on actors, years before RDP. But I believe it still applicable. Partial failure, graceful degradation, fallback services and resilience is something we can achieve in computing much more effectively than in nature. Regards, David Barbour [1] http://awelonblue.wordpress.com/2011/05/21/comparing-frp-to-rdp/
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
