Recombinant Computing Evan Welbourne, 590UC

Problem: Interoperability Future UbiComp environments: “Combinatorial explosion” of devices and services Each addition should add value to the entire network Challenges for a solution: no foreknowledge must discover, accommodate must be flexible and generic

Solution: Recombinant Computing Three Foundation Technologies: - Component arch + Resource Discovery + Mobile Code Basic Premises: Fixed, domain-independent interfaces Mobile code User-in-the-loop Allows users to “recombine” devices for previously unplanned tasks

Why Not Jini? Why is recombinant computing better than related work? Sun’s Jini also uses mobile code to support extensibility but doesn’t separate semantics from syntax in interfaces e.g. getName(), getPrinterType(), … HP’s Cooltown uses HTTP for a fixed, universal interface but is limited by constraints on data types and protocols Stanford’s iRoom allows tuple sharing with an event heap but isn’t scalable and requires prior agreement on tuples

Embodied Solution: Speakeasy A component-based embodiment Connection-oriented: - components connect and exchange objects - objects are “leased” and expire after a timeout - calling component’s context is provided to callee Component functionality expressed through interfaces: Original set of Interfaces: - Connection, Context, Control Evolved into: - Data transfer, Collection, Metadata, Control Interfaces implement generic communication “patterns”

Data Transfer Interface Challenge: A wide variety of transfer protocols and data types in use, how do they interoperate? Approach: 1 Setup connection with a public communication “pattern” 2 Sender sends ‘source-provided endpoint’ to receiver 3 Data over private interface with appropriate protocol 4 Receiver accepts byte-stream from endpoint A 3rd party can initiate this transfer receiver sender SPE

Discovery Protocol Bridge Collection Interface Challenge: Need extensible discovery protocols, and a way for users to cluster components together Approach: 1 Return an object representing the aggregate 2 Object allows search on its components 3 Object allows queries on membership changes Example Collection Interfaces: - Filesystem aggregates directories - Bridge to another network with different protocols Discovery Protocol Bridge

Contextual Metadata Interface Challenge: Allow sensemaking of components without hardcoding semantics Approach: 1 Caller sends a metadata object to callee 2 Object contains an extensible list of key-value pairs 3 User or inference engine interprets or ignores metadata 4 Metadata object can dynamically update metadata Examples Keys: - Name, Location, Administrative Domain, …

Control Interface Challenge: Allow component-specific control without prior agreement or foreknowledge Approach: 1 Multiple UIs for each component (e.g. GUI, HTML) 2 Caller can indicate the type of UI it wants 3 Callee sends component-specific UI object to the caller 4 Caller interacts with callee using the UI object Example UIs: - UNIX pipes, web browser, form wizard Drawbacks: - Must explicitly write UIs for each component or use UIML - UI should be amenable to non-human control

Applications A number of possible paradigms: UNIX pipes, scripting languages, dataflow diagrams, browser-style drag-and-drop, form-wizard Assuming user interaction via a “resource poor” device (PDA, cell phone) Implemented the HTML-based Speakeasy browser: - Supports discovery, connection, and interaction - Direct-connect mode allows access to raw functionality - Task-oriented templates offer intelligent task prototypes - New templates can be created by example and shared

CSCW – Adhoc P2P Collaboration Casca: an application for adhoc P2P collaboration - Creates “converspace” across machines and networks - Allows sharing of files, services, devices,… - Uses Speakeasy to allow “spontaneous” collaboration Casca avoids the limitations of similar P2P systems: - share only a fixed set of resources (Napster, mp3s) - limited resource discovery - assumes interest in all peers - restricted network transport

User Evaluation Evaluating the Speakeasy browser: 2 evaluations First evaluation (5 users, 2-week period) - Users given PDA with mockup browser - Asked to setup and give a presentation, with hints - All but one were able to form and use a mental model Second evaluation (6 users, ?-week period) - Users given PDA with real browser - Same task, but using templates and no hints given - One of six couldn’t complete task without intervention Users were confused by large number of components Users found a lack of feedback on the state of the world

Questions – User oriented Is this the right user-model for UbiComp? Explicit connections demand user’s attention What is the limit to user-in-the-loop computing? Tangible and non-display interfaces? Whiteboard? Is a collection interface the right abstraction? User has to think about system: network bridge, etc Heterogeneous collections? Can a collection be automatically created? Has there been enough ongoing evaluation? Is it the right kind of evaluation?

Questions – System oriented Multi-standard service interoperation problem Speakeasy uses single-standard services Says service standards should be domain independent

References Slide 1-2 images: Siemens Webzine (http://w4.siemens.de) Other images from Google image search or the following papers: W. K. Edwards et. al.: “The Case for Recombinant Computing” “Using Speakeasy for Ad Hoc Peer to Peer Collaboration” “Challenge: Recombinant Computing and the Speakeasy Approach” M. W. Newman et. al.: “User Interfaces When and Where They are Needed: An Infrastructure for Recombinant Computing” “Designing for Serendipity: Supporting End-User Configuration of Ubiquitous Computing Environment”