Recombinant Computing

1. Recombinant Computing Evan Welbourne, 590UC

2. 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

3. 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

4. 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

5. 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”

6. 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 receiver3 Data over private interface with appropriate protocol4 Receiver accepts byte-stream from endpoint • A 3rd party can initiate this transfer receiver sender SPE

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

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

9. 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 wants3 Callee sends component-specific UI object to the caller4 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

10. 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

11. 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

12. 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

13. 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?

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

15. 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”