-
Notifications
You must be signed in to change notification settings - Fork 1
Home
Please note this wiki relates to TELSTAR 2.0 only. Telstar 1.0 is no longer under development.
TELSTAR is both a viewdata system and a viewdata service. The articles here relate mainly to installing and managing a standalone Telstar system. Details of the Telstar viewdata service can be found at https://glasstty.com along with details of the the Telstar Viewdata Client and details of how to connect to the service.
The TELSTAR viewdata system, described here, provides a simple viewdata/videotex platform similar to those that were prevalent during the 1980s such as Prestel (https://en.wikipedia.org/wiki/Prestel).
The viewdata 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 (https://glasstty.com) can be used with modern computers (macOS, Linux, Windows).
Telstar is implemented as a simple TCP service which makes it fairly simple to integrate the system with the Asterisk telephone system and the BPQ32 Packet Radio node as well as other TCP aware applications.
The system adheres to the standards used by British Telecom's Prestel system as far as is practical and includes the following features.
- Full duplex operation
- Support for response frames
- Support for Telesoftware frames
- Extensible via a very simple plug in mechanism
- Support for pages with frames exceeding 26 using Zero Page Routing
- Support for external frame editors such as Edit.tf and ZXNet.
- Full duplex bi-directional Gateway frames to other viewdata and non-viewdata systems.
- TCP Service providing simple integration with Telephone and Packet Radio systems.
- Baud Rate throttling to provide realistic 1970s transmissions speeds over TCP.
- API for content and user management including bulk uploads from the local filesystem or a GitHub repository.
- Primary and secondary database storage allowing content to be viewed before being published.
TELSTAR is designed to run in a Docker environment and is supplied as a series of Docker images. These are easy to install and are described below.
The system comprises of several components, each of which run in their own container, the containers are connected to each other by a docker network and each container has access to a shared volume for file storage.
The following is a list of the essential components
- Telstar Server - The Telstar Server is a simple TCP service that can handle multiple connected clients it is not a Telnet service.
- MongoDB database - Viewdata frames are stored within the MongoDB database as json objects. This allows frame metadata such as custom routing, text headings, navigation messages etc.
- Telstar API - The Telstar API is a restful API that allows json formatted frames to be uploaded and managed. In addition user management can be performed.
In addition the following highly recommended components allow the system to be easily managed using a web interface
- Mongo Express - This provides a web interface to the MongoDB database.
- Portainer - This provides a web access to the running containers.
As is typical with interactive viewdata 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).
Content for the system is based on simple json files which include the page content as we as frame metadata such as custom routing, text headings, navigation messages etc. There are several frame types that can be defined within the frame's json file, this makes it very simple to define basic information frames, gateway pages, response frames etc. and content can be defined as plain text, markup, or by using one of the popular frame editors such as Edit.tf (https://edit.tf) and ZXNet (https://zxnet.co.uk/teletext/editorfor).
Frames are added and deleted using a cross platform command line utility, telstar-util, which provides a very simple way to access to the remote Telstar API. In addition, telstar-util can be used to perform bulk uploading of frames from either the local filesystem or from a remote git repository such as those provided by GitHub (http://github.com).
Whilst telstar-util provides a simple means of managing content via the API, the Telstar API is a restful API and can be used directly by any software making it simple to integrate into existing workflow as required.
Further details of the Telstar API and the command line utility can be found in the section The Telstar API.
There are several frame types that can be defined within the frame's json file, this makes it very simple to define basic information frames, gateway pages, response frames etc.
Full details of all of the frame types and how to create them is described in the section Frames.
Response frames are frames that allow a user to enter data that is 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.
As an example the Telstar Service (https://glasstty.com) weather page is handled using a response frame 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 Response Frames.
Routing in Telstar is handled by a full duplex asynchronous process that allows for routing to occur whilst pages are being rendered. This means that 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 viewdata 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.
Full details of page numbering, zero-page routing and how to modify routing tables can be found in the section Routing.
Details of how to install Telstar are detailed in the article Installing Telstar. Telstar can be configured and customised as required, see Configuration Options for details. Once the system is installed and running it can be managed using Portainer, see Managing Telstar with Portainer.
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).