Here's a quick blurb from http://oxygen.lcs.mit.edu/Software.html Lots of references to software components, object oriented software, persistance. These are some key buzzwords, and in fact, key concepts in software engineering which must become fully understood before much of this stuff makes sense. I believe they are also building new types of hardware which can perform in this highly multiprocessing environment. Object oriented software and component based software are not new. Microsoft claims to build using these philosophies, but they are not even close. To do it right will require a rethinking of everything down to the kernel, and hardware which can support the new paradigm correctly. Security will need to be intrinsic, not an afterthough. Approach Project Oxygen's software architecture provides mechanisms for building applications using composable, distributed components, customizing, adapting, and altering component behavior, replacing components, at different degrees of granularity, in a consistent fashion, person-centric, rather than device-centric, security, and disconnected operation and nomadic code. Oxygen's software architecture relies heavily on abstraction to support change through adaptation and customization, on specification to support components that use these abstractions, and on persistent object stores with transactional semantics to provide operational support for change. Abstraction Computations are modular, as is storage. Abstractions characterize components that carry out computations and objects used in computations. In Oxygen, abstractions support the use of adaptable components and objects by providing application access to components traditionally hidden beneath intervening layers of software, so as to observe and influence their behavior, intent-based interfaces, not just syntax or address-based interfaces, so as to facilitate component and object use, adjustment, replacement, and upgrade, stream-oriented interfaces that treat speech, vision, and sensor data as first-class objects, so as to enable compilers to manage low-level pipelining concurrency and multithreaded programs to adjust their behavior correctly at runtime in response to changes in the number of streams or the interactions among them, constraint and event abstractions, which separate computation from control, trigger what is processed when, and provide flexibility for modifying behavior at runtime without compromising system integrity, cutpoints, so as to provide safe fallbacks and to enable "eternal computation". Specifications Specifications make abstractions explicit, exposing features to other system components. In Oxygen, specifications support adaptation and change by providing information about system configurations, to determine what modules and capabilities are available locally, module repositories, to provide code over the network for installation on handheld and other devices, module dependencies, to support complete and consistent installations or upgrades, module capabilities, to support other components and applications in scripting their use, and module behavior, to support their safe use through a combination of static and runtime checks. Persistent object store with transactional semantics Code, data objects, and specifications reside in a common object-oriented store, which supports all Oxygen technologies (i.e., user, perceptual, system, and device technologies). Object-orientation helps maintain the integrity of the store by restricting updates to those performed by methods in the store. The store has transactional semantics, which enables concurrent access, rollback and recovery, and consistent updates to modules and data. It also operates efficiently, using techniques such as optimistic concurrency, pre-fetching, and lazy updates and garbage collection, which defer the costs of modifying the store as long as possible or until there is time to spare.
