Activity Sharing and Networking
From XOCPWiki
This page will document the networking-related development efforts centered around making Classroom Presenter a shared, collaborative activity.
Contents |
Overview
The heart of Classroom Presenter is its collaborative nature. It is thus a shared activity by which students and teachers can collaboratively engage in a lesson plan via the sharing of slides. To accomplish this, Classroom Presenter makes use of the many networking services and libraries available on the XO; specifically the Sugar software platform.
Links
- XO Activity Sharing Concept
- Telepathy - Networking on the XO.
- Tubes and the Tubes Tutorial - How XOs communicate within a shared activity
- D-Bus Tutorial and API from the official DBus site.
- XO Presence Service - Infrastructure for shared activities on the XO.
- HelloMesh activity - A very useful example of using dbus tubes.
- Read activity - The defacto example for using stream tubes.
- Simple Wifi Tests on candidate-703.
- Debugging Telepathy
Goals
- 1) (Done) To allow the instructor to turn on "locked mode" on the student machines that have joined the activity. In this mode, the students' machines automatically follow the instructor's presentation. This means that when the instructor changes to a particular slide, all the students' views will move to that slide as well. When in "unlocked mode," the students are free to navigate the presentation on their own. The ability to turn "lock mode" on and off rest solely with the instructor's machine.
- 2) (Done) For an XO joining a Classroom Presenter activity to automatically download (and then display) the slide presentation from an XO, student or instructor, that already has it.
- 3) (Done) For students who have added ink to an activity slide and/or typed textual responses to submit those to the instructor. The instructor is then able to browse through the received submissions.
- 4) (Done) After receiving submissions, the instructor is then be able to chose submissions (one at a time) that are then broadcast back to each student. The instructor and students can thus view and discuss student submissions together.
Current Issues
- Intermittent stream tube failures causing slide deck distributions to occasionally fail (see Ticket #1).
Architecture
The source files containing the classes that perform all activity sharing tasks are:
What happens:
When Classroom Presenter is started, the creation of the Shared singleton (in shared.py) causes the appropriate hooks for the activity sharing and joining events to be created. Then, if the activity has been shared, the Shared object will assume "instructor mode" and complete all necessary tasks, such as the creation of a dbus tube for signaling and RPC calls and the creation of the SharedSlides (from sharedslides.py) singleton, which in turn creates a stream tube and HTTP server for slide deck sharing. The instructor machine will also begin listening for any instructor-specific signals that the student machines will send. If the activity has been joined, the Shared object finds the dbus tube created by the instructor and then also creates a SharedSlides singleton. In this case, however, SharedSlides will seek an available stream tube and attempt to download the presentation. If this succeeds, the presentation is displayed, the machine will create its own stream tube and HTTP server, and begin sharing the presentation (see Ticket #13). Finally, a signal gets sent back to the instructor machine informing it that the download has completed. Upon receiving this signal, the instructor will push state data, such as navigation lock mode and current slide index, to the student XO. Once this is complete, the student XO has fully joined the presentation.
