The system allowed each student to revise his or her writing and in so doing, it retained a revision history. Each previous version could be retrieved in order to assess the students process and development.
Original writings, commentary and any multimedia materials provided by students had to be approved by the student's teacher before that material became visible to others in the collaboration. The system associated each student with a teacher. Several teachers (and their classes) constituted a single collaboration. Collaborations included classes in multiple schools.
Teachers had an expanded menu that allowed them to approve student work and access administrative functions. Teachers could also edit the welcome screen and navigation bars.
The technologies employed for Streams OnLine allowed it work in labs or classrooms equipped with older desktop computers such as the Mac IIsi or the 386 PC. The school's desktop computers were networked and capable of running TCP/IP and some type of web browser. The inter-school collaboration was carried over email, which can traverse slow or intermittent network connections and could even be used over UUCP or Fidonet. These technological constraints allowed Streams OnLine to be workable world wide.
Teachers were offered additional items on their menu bars. On the top menu bar, they had access to the approval functionality, while on the bottom menu bar they had added access to administrative functionality.
Streams OnLine did not use cookies, frames, java or javascript in order to produce the web pages used by the students. Because of this, Streams OnLine could be accessible in older labs where only older, memory efficient web browsers can operate. It could also be used by text based browsers.
Streams OnLine inter-school collaboration was performed by logging the SQL database accesses that caused any sort of changes to the database. These changes were emailed to partner schools each time a teacher approved a student's work. There was a program called repin that received incoming emailed updates. This program updated the local database and installed any additional files that came in. Because this programs had to change ownership of incoming files, it ran in suid root mode. repin was written in 'C' rather than perl.
In order to bring a new partner school into an existing collaboration, a database synchronization had to be performed by all existing partners. A program called sync.pl handled creating and dispatching the synchronizations, and the same repin program that handled updates also recieved synchronizations from remote partner systems.