Building a Middleware Infrastructure for Capture and Access ...

Building a Middleware Infrastructure for Capture and Access Applications La´ercio A. Baldochi12 , Renan G. Cattelan1 and Maria da Grac¸a Pimentel1 ∗ 1

Instituto de Ciˆencias Matem´aticas e de Computac¸a˜ o – Universidade de S˜ao Paulo Av. do Trabalhador S˜ao-Carlense, 400 – Centro – Cx. Postal 668 13560-970 S˜ao Carlos-SP 2

Faculdades COC Rua Abra˜ao Issa Halack, 980 - 14096-160 - Ribeir˜ao Preto-SP {baldochi,renan,mgp}@icmc.usp.br

Abstract. Capture and access applications automate the capture of and the access to live experiences and are a main theme in the ubiquitous computing research area. Examples of such applications have been built in the educational, office and meeting domains, and most of them make extensive use of network communication, multimedia streaming and storage systems. Despite their common needs and architectural similarities, there is a lack of middleware support for building capture and access applications. The literature reports on efforts towards providing network abstractions that make communication between applications transparent. Leveraging off that work, we present in this paper a set of component-based infrastructures and services providing capture and access applications with abstractions for functionality and distributed data management. To illustrate the utility of our approach, we detail its use in the implementation of a live lecture capture system.

1. Introduction In the beginning of the last decade, Mark Weiser envisioned that computer applications could be embedded in the environment, aiding people without changing the way they perform their activities. This transparent integration of technology in the everyday life was called ubiquitous computing [Weiser, 1991, Weiser, 1993]. Many applications exploit the ubiquitous computing paradigm to support the automatic capture of information in live experiences towards generating corresponding documents for later review. Examples include the educational [Abowd, 1999, Davis et al., 1999, Mukhopadhyay and Smith, 1999], office [Mynatt et al., 1999] and meeting [Pedersen et al., 1993, Richter et al., 2001, Streitz et al., 1994, Wilcox et al., 1997] domains, making extensive use of network communication, multimedia streaming (audio and video) and storage systems. ∗

The authors would like to thank FAPESP, CNPq, CAPES, Fulbright and NSF for their support. (http://coweb.icmc.usp.br/incaserve).

It is a problem that capture and access (C&A) applications have been implemented by following a casual (ad hoc) approach, even though they present many architectural similarities. The development of ubiquitous (or pervasive) computing demands “processing, storage and network infrastructures, as well as development tools” 1 . Previous work reports a solution towards providing network abstractions allowing transparent communication among C&A applications [Truong and Abowd, 2003]. However, the effective building of these applications requires extra facilities such as functionality (or processing) and storage abstractions. Towards matching those needs, we are developing reusable software components that comprise such requirements by encapsulating specific functionalities of C&A applications and providing automatic storage of the corresponding generated documents. We report in this paper a set of component-based infrastructures and services built towards providing applications with abstractions for functionality and distributed data management. We illustrate the use of our infrastructure in the implementation of a capture system for live lectures. This paper is organized as follows: Section 2 presents the INCA infrastructure, responsible for the network abstraction used in our approach. Section 3 describes xINCA, a set of reusable software components comprising the most common functionalities demanded by C&A applications. Section 4 details StRES, our storage service, responsible for managing the information generated by capture-based applications in order to provide ubiquitous access to this information. Section 5 demonstrates the use of our infrastructure in the context of a C&A application in the educational domain. Section 6 compares and contrasts our work to others, specially those related to data management for ubiquitous computing applications. Finally, Section 7 presents our conclusions and future work.

2. Background in Network Abstraction The design of C&A applications has an inherent distributed nature. Usually composed by a confederation of devices and software systems, C&A applications can be truly supported by network abstractions. Moreover, many similarities can be noticed from the designer’s perspective, allowing the building of C&A applications to be conducted according to an architectural approach. Truong and Abowd report on the INCA infrastructure — INfrastructure for Capture and Access Applications — which provides architectural support for building applications through a set of key design concerns [Truong and Abowd, 2003]: • Part of the system is responsible for the capture of information as streams of data; • Part of the system is responsible for the storage attribute-tagged (representing contextual metadata) information; • When information needs to be converted into different formats and types, part of the system must transduce the information; • Part of the system provides synchronous access to multiple integrated streams of information that are gathered as response to context-based queries. From a software components perspective, each of those concerns has a correspondent module and interface that developers must instantiate and implement in order to build 1

http://www.smartlab.cis.strath.ac.uk/MPAC

their applications. The basic entities are the capture and access modules, which behave like producers & consumers in a peer-to-peer approach. INCA has a Registry entity that automatically controls the presence of all capture and access modules in the system. Capture modules publish the information they provide, while access modules subscribe for the information they want to receive. When published and subscribed attributes match, capture and access modules have the communication flow between them enabled. INCA treats data as large binary objects. Information is assembled as DataObjects tagged with a list of name-value attributes associating meta information about the data. By imposing to data this uniform representation, INCA abstracts specific information issues from the application avoiding that large parts of the applications must be re-implemented when new data types have to be supported.

3. Functionality Abstraction Besides architectural aspects, a large number of C&A applications present recurrent functionalities, e.g. whiteboard, chat, audio, video and weblog capture and access. These functionalities can appear in any combination and suggest a component-based approach. With this in mind, we developed xINCA (Extended INfrastructure for Capture and Access Applications) as a layer on top of INCA, making use of its modules and abstractions. Using xINCA, a new C&A application can be built by means of the combination of the software components demanded — components that communicate using a session identifier. A session represents a period of interaction between components and must have a unique identifier as long as it lasts. New components can be added or removed at any moment during a session. The xINCA components implement instances of capture, access or both INCA modules. These modules are registered under a session identifier at runtime in a INCA’s Registry, which can be local or remote. Component’s modules registered under the same session identifier are able to exchange data. Figure 1 depicts the communication flow between components in two simultaneous sessions.

Figure 1: Communication flow between xINCA components in two simultaneous sessions [Baldochi et al., 2002]

In Figure 1, App#1 is a C&A application with a chat component and a whiteboard component, App #2 is a capture and access application with a chat component and App #3 is an access-only application with a whiteboard component. The chat components of App #1 and App #2 are registered under the same session identifier (Session #1) and, consequently, have an active communication channel that allows them to exchange information. Similarly, the whiteboard components of App #1 and App #3 are registered under a same session identifier (Session #2) so that they can exchange data. However, the communication flow among App #1 and App #3 is unidirectional since App #1 captures information in the whiteboard while App #3 only access that information. It is important to notice that the access to the captured information provided by xINCA components occurs only during the lifetime of the session. The information captured by a certain peer is made available to other peers by means of callback methods defined in a set of programming interfaces. Each functionality has its own programming interface, that must be implemented by the application in order to make the component available. The storage of the contents generated during the capture phase is an application task. However, we provide data management services in order to make this task as easy as possible, improving, this way, the support for developers of C&A applications.

4. Data Management for Capture and Access Applications The recent improvements in Internet backbone bandwidth together with the growing offer of broadband connectivity for a reasonable cost and advances in wireless technologies are turning the visions of Weiser into reality. However, connectivity and gadgets aren’t worth much without ubiquitous data access. Providing pervasive storage to applications requires new techniques in data management, as data needed to support background activities must be reliably and efficiently stored, queried, and delivered. Three main topics in ubiquitous computing present data management challenges that must be overcame in order to provide true pervasive data access to applications. These topics are [Franklin, 2001]: • Support for mobility: applications must be able to operate in heterogeneous and dynamic communication and computation environments, and they must be able to move from one network or service to another; • Context awareness: as systems and applications evolve and become truly ubiquitous, devices tend to be used constantly in a wide range of activities. The constant support for informal activities common in our everyday lives was called everyday computing [Abowd and Mynatt, 2000]. In order to provide this support, applications must be aware of the environment and of the users and their activities. So, the underlying data management system must provide ways to encapsulate, store and retrieve context information. • Support for collaboration: a large number of systems have been developed to support group activities in domains that include meetings and education. This support consists not only in providing communication facilities, but also in providing effective management tools to store, maintain, deliver and present shared data.

As far as the support for collaboration is concerned, C&A applications are pioneer endeavors in the field of ubiquitous computing. A case in point is PhoneSlave [Schmandt and Arons, 1985], a program designed to provide audio “form filling” by asking a series of questions as an answering machine. During the last decade many C&A systems have been built in order to capture specific activities [Abowd, 1999, Davis et al., 1999, Mukhopadhyay and Smith, 1999, Mynatt et al., 1999, Pedersen et al., 1993, Richter et al., 2001, Streitz et al., 1994, Wilcox et al., 1997, Dey et al., 1999]. As these systems were developed as ad hoc efforts, the goal of our work is to provide infrastructures to support the development of C&A applications targeted to different, non-specific domains, avoiding, this way, repetitive coding and ad hoc solutions. In order to achieve this broader goal, a narrower one must be addressed: how to manage the information generated by applications in order to provide ubiquitous access to it. 4.1. The xINCA-StRES Approach Our aim is to provide infrastructure support for (a) the capture of live activities and for (b) the access of the captured content. Following the approach used by INCA and its Registry service, we developed a service-based data management system called StRES – Storing, Retrieving and Extending Service. The development of StRES faced, at first, the challenge of how to represent the information produced in live capture sessions. Based on the analysis of use cases, where we considered that our infrastructure had to provide storage facilities for a wide range of capture-based applications, from lectures to distributed cooperative meetings and everyday activities, we modeled each session as a XML document. While this approach was mainly motivated by the need to exchange information between the many modules that make up our infrastructure, it also facilitates the interchange of information among third-part applications. In order to define the structure and the content of each session document, the first step was to define data schemas for all xINCA components. Next, we defined a schema for the whole session, since the resulting document is supposed to be conformant to this schema. As a result, this main schema, named session schema, aggregates the schemas of all xINCA components together with a contextual schema, which contains contextual information about the session, such as the name of the people involved, the location(s) where it took place and when it happened. We used the session schema as the input for a binding mechanism called JAXB (Java Architecture for XML Binding) [Sun Microsystems, Inc., 2002]. JAXB compiles each schema into a set of Java classes. The classes generated handle all the details of XML parsing and formatting, allowing developers to build applications that can read, manipulate and create XML documents without writing any logic to process the documents’ elements and attributes. A detailed example explaining the definition of schemas for xINCA components and the generation of Java classes using JAXB is found in [Baldochi et al., 2002]. Besides the classes produced by JAXB, it was necessary to write the class that handles the transduction of each component’s data into XML documents. This class,

called Transducer, instantiates xINCA access components for each xINCA capture component present in the application. It also instantiates objects from the classes generated by JAXB. Using the xINCA access components, the Transducer receives all the information produced by the application’s xINCA capture components and transduces this information to the objects provided by the data binding mechanism. Our infrastructure hides all these implementation details from the application developer. In fact, all the developer must do to provide storage facilities to applications is to instantiate a StorageComponent object, passing a set of parameters that includes a session identifier and contextual information related to the session. The session identifier is an unique id used to associate INCA modules to their respective sessions. The contextual information determines what type of transducer must be instantiated and defines whether the application is local or distributed. This last feature is quite important for the design of our storage service. It indicates that a session may be distributed, meaning that it may have many peers connected through a network. In this case, each of its peers represents part of a distributed application that generates information that must be stored in a single document. Therefore, the instantiation of a StorageComponent object does not mean the instantiation of a Transducer, which is instantiated only once, when the first peer of the application starts. The rest of the peers belonging to the same session just join an existing Transducer. In order to allow sessions in which peers are added and removed dynamically, we implemented a daemon that is responsible for maintaining Transducers related to active sessions. This daemon, called Sessiond, accepts connections from peers willing to have the information they produce automatically stored. Sessiond maintains two lists: one holding the sessionIds of all active sessions and the other containing the respective Transducer objects instantiated to process each session. Upon the receipt of a new connection, Sessiond checks the list of active sessions to verify whether the sessionId just received already exists in the list. If it does, Sessiond retrieves the appropriate Transducer object and calls its join method, passing to the transducer the information related to the new peer. Otherwise, if the new sessionId is not included in the list, Sessiond instantiates a new Transducer object, passing to its constructor all the parameters described earlier. INCA and xINCA provide callback mechanisms to report the occurence of events related to modules and components. Using a callback provided by INCA, Sessiond is able to determine the end of a session, and then call a method on its respective Transducer causing the generation of the XML document that represents the captured session. 4.2. Building a Distributed Document Repository After addressing the challenge of providing an automatic mechanism for the generation of documents that represent captured sessions, our next goal was to built a document repository able to provide reliable and efficient operations for storing, retrieving and quering captured sessions. In the design of such repository, we had to consider the distributed nature of its target applications. As the number of applications built with INCA/xINCA grows, it is necessary to provide two or more Registry entities, especially when those applications run in disparate networks. For efficiency reasons, the same applies to the storage service: it is highly desirable to have a repository available in the same LAN as its client applications

(or, at least, as close as possible to most of each application’s peers). This implied the necessity to implement a distributed storage mechanism. As we needed to store, retrieve and query XML documents, we decided to build our data repository using the facilities provided by eXist [Meier, 2003], a native XML database. eXist functionality is based on hierarchical collections, similar to the storage process in a file system. Besides the facilities for creating and removing collections, storing and retrieving documents, eXist also provides a query mechanism based on XPath [Clark and DeRose, 1999]. eXist also provides a XML-RPC API, which we modified in order to implement our distributed storage service. Our strategy to build a distributed repository consists in brokering the communication between applications and their local repository. In order to achieve our goal, we replaced the XML-RPC interface of eXist by an entity called Document Manager (DocMan for short), which is basically an extension of the XML-RPC server provided by eXist. According to this extension, all method calls that change the state of the local repository are spread to all other active repositories. The list of active repositories is kept in an XML document, called hosts, which is stored in the root collection of each repository instance. The hosts document is constantly updated by a server that works somehow like a lookup server. When a repository starts, it only knows the address and port of this server. In its startup process it registers itself in this server, which then updates its list of active repositories and saves this list in a XML document. After that, the server stores this document in the root collection of all active repositories. A similar procedure occurs when one of the active repositories shuts down. As can be easily noticed, our distributed storage policy is based on the full replication of XML documents. This policy is widely used for the storage of regular data in distributed databases. StRES, however, presents a set of features that make it quite different from a traditional distributed database system. The main difference is that documents generated by C&A applications are somehow like pictures, meaning that they describe events that happened in the past. So, these documents remain unchanged, considering that an update to their content signifies changing the past. This assumption had diminished considerably the complexity of our distributed storage mechanism, since issues related to the propagation of updates did not need to be considered.

5. The iClass System Our infrastructures and services have been used to support capture and access applications in different domains. Previous work has reported the development of a toolkit for distributed meetings [Baldochi et al., 2002]. Other examples include investigation in the field of opportunistic meetings and applications built by researchers new to the area of automated capture. In this section, we will describe the general steps taken in the design and implementation of the iClass System, a live lecture capture application which makes extensive use of xINCA’s and StRES’s abstractions. Similar in functionality to the eClass, formerly Classroom 2000, developed at Georgia Tech [Abowd, 1999], the iClass System is able to record several pieces of information produced during the lecture, including strokes and slides from an electronic whiteboard, audio from a cordless microphone attached to the

lecturer, video from a inexpensive web camera located in a fixed position in the classroom and web pages visited from the lecturer’s web browser. As a result, at the end of the lecture, a XML document integrating the different captured media is produced and automatically processed to create documents in a variety of presentation formats. The core of the iClass system consists basically of a Java applet comprising one or more capture components and a storage component. The capture components, one for each functionality (whiteboard, audio, video and web logging), are instantiated in the beginning of the lecture according to the instructor’s choice or available devices. The storage component is responsible for contacting a server (Sessiond) informing which capture components are running on the client. Then, the storage service instantiates a Transducer containing the corresponding access components, which will receive the information produced by the capture components running at the client applet. Using a callback mechanism, access components deliver the received information for being stored by the Transducer. Components of a specific session (lecture) are registered under the same session identifier allowing several sessions to happen simultaneously. Figure 2 depicts the iClass architecture according to the phases suggested by [Abowd et al., 1996] for structuring the problem of capture and access: (1) preproduction, (2) live recording, (3) post-production and (4) access, with the second and third ones concentrating the core of capture and storage processing.

Figure 2: The iClass architecture

5.1. Pre-Production The pre-production phase is related to the session setup and to the gathering of contextual information. It is application’s responsibility to manage its own specific information. Different applications deal with different contexts and thus manage their specific data in different ways. Our infrastructures and services do not treat such high level of abstraction. We do not impose any strict restrictions to the application’s contextual data. We only require that applications associate unique identifiers to pre-defined basic entities. For instance, the activity captured by the iClass system is a lecture. Each lecture has some particular context such as the lecturer’s name, when it happened, where it took place, the course it belongs to and so forth. This is the application context. Our infrastructures, on the other hand, deal with usernames, timestamps, locations and session ids. These basic entities come from the binding process and thus are already conformant with the document grammar (DTDs) they will be converted to. Their identifiers will be in fact the links between the facilities we provide and the application’s specific context. So, the first thing the application developer must do is conveniently treat the application’s specific contextual data, by, for instance, modeling and implementing a relational database as done for the iClass System. The developer can, optionally, implement the GUI for the application’s setup. Figure 3 shows the iClass’s web form for lecture setup which gather contextual information such as the course name, lecture subject, term, datetime information and the lecturer’s username and password. The pre-production phase is the most laborious one due to its context-related behavior. In the next phases, our infrastructure is more effectively used, relieving developers from complex tasks.

Figure 3: Web form for lecture setup

5.2. Live Recording Once having the capture session properly set up, the application developer determines what kind of support is required for her application. This is done by the instantiation of the desired components which act as producers, consumers and/or storers in a distributed peer-to-peer network. A Java applet instantiates a StorageComponent and xINCA capture components for whiteboard and, optionally, for audio, video and web logging. The StorageComponent contacts the Sessiond, starting the server-side storage process: the Sessiond instantiates a Transducer with xINCA access components for the chosen functionalities. As the components get registered under the same session identifier, they start to exchange information. Everything occurs seamlessly and the developer does not have to care about network, processing or storage issues thanks, respectively, to INCA, xINCA and StRES. 5.3. Post-Production The Sessiond is made aware of activity in the INCA’s Registry through callback methods received from a Observer object it instantiates. When there is no more active capturers for a specific session, the Sessiond calls a stop() method in that session’s Transducer causing the marshaling of a XML document and the ending of the session. As the resulting XML document represents the captured session, it is stored in the repository managed by StRES. An example of the generated XML document is shown on Figure 4. It is important to notice that the XML document contains, mostly, metadata. The captured media, such as image, audio and video files are stored in the host’s repository file system. The XML document, however, contains the URLs of each multimedia file generated during the capture of a lecture.

Figure 4: XML document (expanded to the 3rd level) representing a lecture captured by the iClass System

Before storing the XML document in the repository, we submit it to a XSLT processor in order to produce files that are ready to be presented in browsers and multimedia players. Using a set of XSLT stylesheets we generate the following file formats: HTML, SMIL and XHTML+SMIL. These files are kept in the file system, in the same directory as the multimedia files. 5.4. Access Once the capture process is finished, we need to provide access to the captured content. In the access phase, the developer makes use of the API provided by StRES to retrieve the data kept in the repository. Using the API, applications may submit XPath-like queries over document collections in order to retrieve the URLs for accessing the desired content. Like the application’s setup GUI, the developer implements the application’s access GUI according to her personal preferences and needs. Again, there are contextrelated implications. Part of the information required for building the GUI may need to be retrieved from the application’s context specific database. For the iClass System, a web interface (see Figure 5, background) was built using PHP scripts. An hierarchical structure of years, terms and courses (retrieved from the iClass database) is presented to the user in dynamically-built web pages allowing them to reach a particular set of lectures. Each lecture has its own identifier, which is, in fact, the session id used to submit queries to the repository. These queries return the URLs to the documents of the lecture. Figure 5 (foreground) shows a captured lecture’s SMIL document being presented in RealOne PlayerT M . Captured slides are presented synchronously with captured audio. Besides the presentation formats generated in the post-production phase, we also provide a Java applet that can be used to playback slides in the stroke level.

Figure 5: iClass System’s access interfaces

6. Related Work Our data management approach to deal with information produced by C&A applications is related to a wide range of previous and on-going work. That’s mainly because a significant research effort has been driven towards providing ubiquitous access to shared data in the World Wide Web. As a broader goal, researchers intend to provide the Web with features that allow applications to treat it as a global-scale database. Although this goal seems ambitious, several projects have already accomplished advances towards it – examples are Coda [Satyanarayanan et al., 1990], Chord [Stoica et al., 2001], PAST [Rowstron and Druschel, 2001], Ivy [Muthitacharoen et al., 2002], Freenet [Clarke et al., 2002] and OceanStore[Rhea et al., 2003]. With the exception of Coda, one of the important principles shared by those projects is the consideration that the client-server model is not the most appropriate for building a ubiquitous, global-scale data management system. Instead, their authors advocate that peer-to-peer solutions are more adequate, as they don’t present centralized nodes of control, allowing the implementation of more reliable and dynamic services. [Bernstein et al., 2002] outline the pros and cons of both client-server and peerto-peer architectures, showing a clear tradeoff between services and startup costs, as the former is rich in services but requires considerable overhead to launch and has a relatively static, controlled architecture, and the later is a dynamic, anyone-to-anyone architecture with little startup costs, but limited services. The tradeoff between overhead costs and high level services has divided the research in ubiquitous computing in two main categories: ad hoc and infrastructureenabled. The first investigates data management issues in environments where data sources and data sinks are connected through slow, unreliable and heterogeneous peerto-peer networks. The second investigates the use of infrastructures built upon broadband connected, resource rich computers, used to overcome the limitations of thin clients such as PDA’s. The role of the infrastructures is to store and provide information to, or perform computation on behalf of, resource-constrained clients. In most of the cases, infrastructures appears in the form of services deployed in a client-server fashion. In the following paragraphs we present some of the most relevant examples of infrastructure-enabled support for ubiquitous computing. Portolano [Esler et al., 1999] and Appliance Data Services [Huang et al., 2001] are projects that investigate ways to integrate input-centric appliances, such as digital cameras and PDAs, into the existing computing environment, making it easier to move data seamlessly among heterogeneous devices. Our work also deals with input-centric devices. However, we are more interested in the metadata that can be generated by those devices, as we use this metadata to produce documents that represent captured sessions. The iRoom [Johanson et al., 2002] project presents an infrastructure that augments meeting rooms with wall-sized touch screens, projectors, microphones, speakers, PDAs and laptops. The main goal of this project is to support work group activities by providing interaction with the instrumented physical space. This project presents several similarities with ours, supporting almost the same set of input devices that we do. The differences lie in the target application domains: our infrastructure is designed to support

a wide range of domains, while theirs is targeted specifically to the office and meeting domains. EasyLeaving [Brumitt et al., 2000], Aura [Sousa and Garlan, 2002] and Gaia [Roman et al., 2002] are examples of projects not targeted to specific physical spaces or application domains. They envision interactive and programmable living and working spaces, where C&A is one within many applications that exploit appliances integrated in the environment. These projects address issues out of the scope of our work, such as sensing and tracking people and objects. By focusing our work on C&A issues, we are able to provide specific services for applications using the facilities provided by more generic middleware infrastructures.

7. Conclusions The effective building of C&A applications requires facilities such as functionality (or processing) and storage abstractions. Towards matching those needs, we are developing reusable software components that comprise such requirements by encapsulating specific functionalities of C&A applications and providing automatic storage of the corresponding generated documents. This work is an extension of previous research, held at Georgia Tech, that exploited the architectural similarities of C&A applications. Our resulting infrastructures comprises reusable software components that leverages the development of applications, allowing their construction by the assembling of desired components. A data binding mechanism is used to automatically generate classes that manipulate the information produced by each component and are reused in both client and server portions of applications. Our infrastructures also address data management issues, providing ubiquitous access to the data produced by C&A applications. The implementation of iClass, a live lecture capture system, illustrates the use of our infrastructures. Up to now, 120 lectures from 8 different graduate and undergraduate courses have been captured using iClass at ICMC-USP. 2 Our future work includes improvements in the binding process while replacing DTDs by XML Schemas and the development of middleware for context treatment, aiming at offering support for the development of applications targeted to the capture of informal and opportunistic activities.

References Abowd, G. (1999). Classroom 2000: An experiment with the instrumentation of a living educational environment. IBM Systems Journal, 38(4):508–530. Abowd, G., Atkeson, C., Feinstein, A., Hmelo, C., Kooper, R., Long, S., Sawhney, N., and Tani, M. (1996). Teaching and learning as multimedia authoring: The classroom 2000 project. In Proceedings of the ACM Multimedia Conference, pages 187–198. Abowd, G. and Mynatt, E. (2000). Charting past, present, and future research in ubiquitous computing. ACM Transactions on Computer-Human Interaction, 7(1):29–58. 2

The captured lectures are available in the following URL: http://catuaba.icmc.usp.br/iclass.

Baldochi, L., Cattelan, R., Pimentel, M., and Truong, K. (2002). Automatic generation of capture and access applications. In Proceedings of the 8th Brazilian Symposium on Multimedia and Hypermedia Systems, pages 100–115. Bernstein, P., Giunchiglia, F., Kementsietsidis, A., Mylopoulos, J., Serafini, L., and Zaihrayeu, I. (2002). Data management for peer-to-peer computing: A vision. In Workshop on the Web and Databases, WebDB 2002. Brumitt, B., Meyers, B., Krumm, J., Kern, A., and Shafer, S. (2000). Easyliving: Technologies for intelligent environments. In Second International Symposium on Handheld and Ubiquitous Computing (HUC), pages 12–29. Clark, J. and DeRose, S. (1999). XML path language (XPath) version 1.0. W3C Recommendation - Available in: http://www.w3.org/TR/xpath. Clarke, I., Hong, T., Miller, S., Sandberg, O., and Wiley, B. (2002). Protecting free expression online with freenet. IEEE Internet Computing, 6(1):40–49. Davis, R., Landay, J., Chen, V., Huang, J., Lee, R., Li, F., Lin, J., Morrey, C., Schleimer, B., Price, M., and Schilit, B. (1999). NotePals: Lightweight note sharing by the group, for the group. In Proceedings of the Conference on Human Factors in Computing Systems, pages 338–345. Dey, A., Salber, D., Abowd, G., and Futakawa, M. (1999). The conference assistant: Combining context-awareness with wearable computing. In Proceedings of the Third International Symposium on Wereable Computing, pages 21–28. Esler, M., Hightower, J., Anderson, T., and Borriello, G. (1999). Next century challenges: Data-centric networking for invisible computing. In MobiCom’99, pages 256–262. Franklin, M. J. (2001). Challenges in ubiquitous data management. Lecture Notes in Computer Science, 2000:24–33. Huang, A., Ling, B., Barton, J., and Fox, A. (2001). Making computers disappear: Appliance data services. In Mobile Computing and Networking, pages 108–121. Johanson, B., A., F., and T., W. (2002). The interactive workspaces project: Experiences with ubiquitous computing rooms. IEEE Pervasive Computing, 1(2):67–75. Meier, W. (2003). eXist open source XML database. Available in: http://exist-db.org. Mukhopadhyay, S. and Smith, B. (1999). Passive capture and structuring of lectures. In Proceedings of the ACM Multimedia Conference, pages 477–487. Muthitacharoen, A., Morris, R., Gil, T., and Chen, B. (2002). Ivy: A read/write peer-topeer file system. In Symp. on Operating Systems Design and Implementation, pages 481–494. Mynatt, E. D., Igarashi, T., Edwards, W. K., and LaMarca, A. (1999). Flatland: New dimensions in office whiteboards. In Proceedings of the Conference on Human Factors in Computing Systems, pages 346–353. Pedersen, E., McCall, K., Moran, T., and Halasz, F. (1993). Tivoli: An electronic whiteboard for informal workgroup meetings. In Proceedings of the ACM INTERCHI Conference on Human Factors in Computing Systems, pages 391–398.

Rhea, S., Eaton, P., Geels, D., Weatherspoon, H., B., Z., and J., K. (2003). Pond: the oceanstore prototype. In Proceedings of the Second USENIX Conference on File and Storage Technologies. Richter, H., Abowd, G., Geyer, W., Fuchs, L., Daijavad, S., and Poltrock, S. (2001). Integrating meeting capture within a collaborative team environment. In Proceedings of the Third International Conference on Ubiquitous Computing, pages 123–138. Roman, M., Hess, C., Cerqueira, R., A., R., and Campbell, K. (2002). Gaia: A middleware infrastructure to enable active spaces. IEEE Pervasive Computing, pages 74–83. Rowstron, A. and Druschel, P. (2001). Storage management and caching in past, a largescale, persistent peer-to-peer storage utility. In Symp. Operating Systems Principles, pages 188–201. Satyanarayanan, M., Kistler, J., Kumar, P., Okasaki, M., Siegel, E., and Steere, D. (1990). Coda: A highly available file system for a distributed workstation environment. IEEE Transactions on Computers, 39(4):447–459. Schmandt, C. and Arons, B. (1985). Phoneslave: A graphical telecommunications interface. In Proceedings of the Society for Information Display, pages 79–82. Sousa, J. and Garlan, D. (2002). Aura: an architectural framework for user mobility in ubiquitous computing environments. In Third IEEE/IFIP Conference on Software Architecture, pages 29–43. Stoica, I., Morris, R., Karger, D., Kaashoek, M., and Balakrishnan, H. (2001). Chord: A scalable peer-to-peer lookup service for internet applications. In Proc. of the 2001 conf. on applications, technologies, architectures, and protocols for computer communications, pages 149–160. Streitz, N., Geibler, J., Haake, J., and Hol, J. (1994). DOLPHIN: integrated meeting support across local and remote desktop environments and liveboards. In Proceedings of the Conference on Computer Supported Cooperative Work, pages 345–358. Sun Microsystems, Inc. (2002). The java architecture for XML binding - user’s guide. Available in: http://java.sun.com/xml/jaxb/users-guide/jaxb-all.pdf. Truong, K. and Abowd, G. (2003). Inca: A software infrastructure for developing and evolving automated capture & access applications. Submitted to the Fifth International Conference on Ubiquitous Computing. Weiser, M. (1991). The computer for the 21st century. Scientific American, 265(3):94– 104. Weiser, M. (1993). Some computer science issues in ubiquitous computing. Communications of the ACM, 7(6):75–84. Wilcox, L., Schilit, B., and Sawhney, N. (1997). Dynomite: A dynamic organized ink and audio notebook. In Proc. of the Conf. on Human Factors in Computing Systems, pages 186–193.