Telstar Viewdata System

Please note TELSTAR 2.0 is still under development and subject to change.

Introduction

TELSTAR is both a a videotex system and a videotex service. Details of the current videotex service can be found at https://glasstty.com.

The TELSTAR videotex system, provides a simple viewdata/videotext platform similar to those that were prevalent during the 1980s such as Prestel (https://en.wikipedia.org/wiki/Prestel).

The videotex implementation described here can be accessed over the internet using modern *internet modems* in conjunction with historic Viewdata and videotex terminals and home computers of the 1980s. In addition the Telstar Viewdata Client can be used with modern computers (MacOS, Linux, Windows).

TELSTAR is is designed to run in a Docker environment and is supplied as a Docker image (see https://hub.docker.com/repository/docker/johnnewcombe/telstar). The system can be installed with a few simple Docker commands or by using Docker Compose. Telstar can also be run under a Kubernetes environment.

Content for the system is based on simple json files, these are added to the system and updated using a command line utility telstar-util inconjuntion with the Telstar API. Telstar includes support for the popular frame editor available at https://edit.tf.

The Docker image described here is a full implementation of TELSTAR application, and whilst the system is comprehensive, it is fairly simple to set up. In addition the system can be extended using a very simple plugin architecture.

Installation

Telstar is implemented using Docker containers and can be managed using Portainer if desired (see Managing Telstar with Portainer). Details of how to install Telstar are detailed in the article Installing Telstar. Once installed Telstar can be configured and customised as required, see Configuration Options for details.

Once the system installed and running it can be managed using Portainer, see Managing Telstar with Portainer.

Pages and Frames

As is typical with interactive videotex systems, pages are numbered from 0 to 999999999 and consist of one or more frames with the suffix a-z, for example the first frame for page 200 would be 200a, the second 200b and so on (see Routing) for more details). These frames are stored within Telstars's database as JSON objects (see https://www.json.org/) and uploaded to Telstar using a simple command line utility.

The Telstar utility program simply interacts with the Telstar API which is a restful API. This can be used directly by any software making it simple to programitically manage pages and routing information. Further details of the Telstar API and the command line utility can be found in the section The Telstar API.

The simplest frame that can be viewed on TELSTAR would be defined as follows. This would create a simple information frame with some default content.

   {
     "pid": {
       "page-no": 101,
       "frame-id": "a"
     },
     "visible": true,
   }

There are many different frame types that can be defined including basic information frames, response frames that can capture user entered data and gateway frames that allow full duplex connections to other systems. The The Telstar API can be used to all of these frames either using the command line utility (https://glasstty.com/wp-content/uploads/2022/04/telstar-util-2.0.zip) or via custom software as required.

Full details of all of the frame types and how to create them is described in the section Frames.

Response Frames and Plugins

Response frames are frames that allow a user to enter data to be processed i.e. a frame where a user enters data such as a form. The data from these frames would typically be processed using an external program or script referred to as a plugin. The plugin can be any software that can be executed e.g. a binary program or a scripts such as Python or Bash etc. All that is required is that the plugin returns a json result, this would typically be a frame or collection of frames.

The Telstar system https://glasstty.com weather page is handled using a response page and plugin. The user is presented with a response frame asking for a town or city. This is passed to an external plugin written in Go (Golang) which accesses the Openweather API and returns the current weather and forcast as a collection of JSON frames. These are captured by Telstar and presented to the user.

Plugins are simple to create and deploy within a Telstar container and can be written in any language supported by the platform.

Further details of the Telstar Plugin framework and how to create them can be found in the section Implementing Plugins.

Navigation and Routing

Routing in Telstar is handled by an asynchromous process that allows for routing to occur whilst pages are being rendered. This means that is a user of the system can navigate quickly to a desired page by simply entering the page number one character after another. Each successive key press will start the rendering of a page but as each subsequent key is pressed, the rendering is cancelled and the following page is rendered and so on until the desired page is rendered.

For example simply pressing 2 2 2 from the main index page (Page 0a) of the Telstar service will result in the Guardians UK News being displayed. For this to work correctly, all intermediary pages must be present. Creating routes through the system such as the one described above, should be the aim when designing a videotex system.

Users can jump directly to a known page by entering the page number using the format *page#, for example, entering *92# into the current Telstar system will direct you to page 92.

Page Numbering

Pages are defined by a single integer number between 0 and 999999999. Each page can have upto 26 frames denoted by the suffix a-z. Therefore a frame denoted by for example 222b would be the second frame of page 222. The maximum page number length is 9 digits plus the frame suffix.

Zero Page Routing

In cases where a page needs more than 26 frames such as a large Telesoftware program or where a large number of news articles extends beyond frame z, a process of Zero Page Routing takes place. For example if a Guradian news article starting on frame 222z needed a continuation frame, the frame 2220a should be used. If articles continued to frame 2220z and needed further continuation frames, frame 22200a should be used and so on to the maximum page number length (see above).

Default Page Routing

When frames are created an optional routing table can be assigned to the frame, (see Frames) this routing table defines what page is selected when a user enters a digit into their videotex client software.

If a routing table is not defined within the frame, the default routing will be used, for example, pressing 6 whilst on page 222 will try and navigate to page 2226, if this page does not exist, this will return a Page Not Found message, similarly pressing 7 will try and navigate to 2227 and so on. In most cases the default routing will work well, however, when that isn't the case, the table can be created or updated manually as required.

Acknowledgements and Attributions

The website icon is derived from work by Dan Farrimond. This original work and the icon is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license (https://creativecommons.org/licenses/by-sa/3.0/deed.en).