\"\" \"\" \"\"
Go backward to Session Components
Go up to Coordinating Education Sessions
RISC-Linz logo


From the scenarios sketched in the previous subsections, we derive the following requirements that from the users' (lecturer and audience) point of view must be met by an architecture supporting the coordination of distributed education sessions:

Developing Sessions
A lecturer must be able to prepare distributed education sessions without being an expert in network-programming. The difficulty of such an endeavor must in the order of magnitude of developing animated slide shows with the help conventional presentation tools or preparing hypermedia documents with modern publishing tools. Obviously the mental complexity of handling concurrent activities in different locations is larger than for a single-threaded presentation, still the abstractions provided by the system must be in the language of the lecturer rather than in the language of the system. Tools must be provided that support the developing, testing, and debugging process.
Performing Sessions
A lecturer must be able to execute distributed education sessions without being overloaded by management tasks. While other scenarios are thinkable, we focus on applications where a single lecturer is performing and coordinating a session without the help of a crew of supporting technicians. For single classroom sessions, no additional help at all should be required; for distributed sessions with a couple of classrooms a separate floor manager might be advisable.
Accessing Sessions
It must be possible to restrict access to a session but open access should be also supported. Different hosts may play different roles in a session. To contact a session, just the availability of a certain startup software and the knowledge of a simple network address should be required. Access should be possible before the session is started but also during a running session.
Integrating Components
It must be possible to integrate external application programs (browsers, viewers, domain-specific applications) into the session. This requirement is subject to the restriction that the external applications may provide various degrees of interoperability (applications with dynamic linking support versus "closed world" applications). However, as soon as the necessary "interface software" for some application has been developed, it should be possible to use this application as a simple building block for a session.
Coordinating Components
It must be possible to integrate real-time audio and video streams into a session (subject to bandwidth restrictions). Electronic whiteboards must be supported. Transmission of window images from general applications must be supported. Support of slide presentations should be available where the presentation is executed locally but synchronized centrally. Likewise it should be possible to invoke from the lecturer's host general applications on the audience hosts with possibilities for local use by the audience (and to revoke control again). It must be possible to run several applications simultaneously, control their interaction and communication. Input data for these applications may be objects provided by the lecturer; output data may be collected by the lecturer.
Enabling Feedback
Feedback from the audience to the lecturer must be possible ("raise hands"). It must be possible to transmit this feedback to the rest of the audience (text, audio/video, whiteboards, window images, ...).
Integrating Agents
It must be possible to integrate autonomous agents that are loaded and executed on the client hosts.

Additionally, general requirements of distributed systems should be met: a certain degree of fault tolerance, reasonable security standards, support of heterogeneous environments with various kinds of machines and communication protocols.

Maintainer: Wolfgang Schreiner
Last Modification: March 11, 1997

\"\" \"\" \"\"