This page presents the following application scenarios to illustrate how we envision the use of our architecture:
Giving a Talk
The main idea for the giving a talk scenario is to automatically
project the slides in the room the talk is given in as well as to
capture a record of the discussion during the talk. In particular:
- The presentation application and the latest slides are prefetched and automatically installed on a computer in the room the talk is given in. Prefetching the application and slides is important because it makes them available locally and eliminates any dependency on network connectivity during the talk.
- The A/V devices in the room are automatically discovered and the presentation application connects to them.
- During the talk, the audio and video feeds from the room are captured and saved. Additionally, notes taken by audience members may also be saved. The audio, video, and notes can then be made available to the presenter as well as the audience.
The main technical issues for this scenario are:
- The interaction with scheduling services. The hosting organization's scheduling service needs to grant access to the room's devices. It also needs to cooperate with the presenter's scheduling service to locate the latest slides and presentation application and to prefetch them.
- Protecting the organization that is hosting the talk. When giving a talk at a different organization from the presenter's organization, the presentation application may consume a reasonable amount of computing and storage resources on the node it is running on. It may also access the room's A/V devices. But, it should not be able to, for example, scan the hosting organization's intranet or access local file servers. The resources that are accessible to the presentation application thus need to be carefully controlled. Note that access to the room's computing resources can be granted automatically, based on the room's schedule.
A variation of this scenario is the personal jukebox scenario, where the music a person is currently listening to is automatically moved between the different locations, such as that person's home, car, and office. The main difference, when compared to giving a talk, is that music, unlike slides, is typically read-only data, making it more amenable to replication instead of actual moving.
Attending a Meeting
The main idea for the attending a meeting scenario is to automatically
provide a shared repository for exchanging notes, drawings, and other
documents during the meeting and to provide attendants with an overall
record of the meeting, which they can take with them after the
meeting. In particular:
- Based on the personal devices present in a room, such as PDAs or laptops, the repository application suggests an initial participant list. Other participants need to be added explicitly, for example, because they are teleconferencing. For scheduled meetings, the scheduling service can add remote participants to the list.
- Once established, the list of participants and their contact information becomes part of the repository.
- Newly added documents are automatically routed to the shared repository and made accessible to a meeting's participants.
- After completion of the meeting, every participant receives a copy of the repository.
The main technical issues for this scenario are:
- The routing of documents. The repository application needs to discover and identify a meeting's participants meeting participants and route newly added documents between the participants' devices and the repository. Furthermore, at the end of the meeting, the repository contents need to be distributed to all participants.
- The location of the repository. The repository can be located on a centralized server node if all participants are physically present at a meeting, but it may need to be replicated if some participants are not on site.
The Electronic Wallet
The main idea for the electronic wallet, or e-wallet, scenario
is to provide an electronic embodiment of a person's wallet, running
on a PDA or smart cell-phone, which keeps track of itself. In
particular:
- The e-wallet keeps track of cash and automatically synchronizes with a person's bank account, for example, when accessing an ATM.
- The e-wallet keeps track of all purchases, recording electronic receipts, and synchronizes with the personal finance manager.
- The e-wallet provides I.O.U. services between co-workers or friends, keeping track of lattes, lunches, and cocktails.
- The e-wallet can automatically apply for store credit cards or enter sweepstakes. But, the owner can set up privacy profiles to control which information is released to whom.
The main technical issues for this scenario are:
- Secure transactions. Even though the e-wallet is typically very mobile, it needs to reliably and securely discover and interact with many different other devices. It needs to clearly identify other participants and provide transactional guarantees, so that, for example, a payment is made exactly once to the intended merchant and not some other customer. The e-wallet also needs to frequently synchronize its data with, say, the home information appliance, as to minimize the loss of information (and money) when it is lost.
- Scalability. The e-wallet application needs to run with relatively little resources on a small device, yet provide a considerable set of services.