Hosting Frames on Telstar
Getting Started
It is simple to become an Information Provider on Telstar. Three things are needed.
1 – A Base Page
Typically organisations will be given a 3 digit (top level) IP base page and indiviuals will be given one from the users area of Micronot. This can be allocated by getting in touch with John Newcombe (john@glasstty.com). John will also organise setting up Telstar and the automatic import of frame data.
2 – A Publically Accessible GIT Repository
A dedicated publically accessible GIT repository is needed e.g. GitHub (https://github.com/), BitBucket (https://bitbucket.org/) etc. This is where the frames should be stored. Telstar’s bulk uploader will be configured to collect these frames at regular intervals.
3 – Frames
Frames can be created using the online editors at https://zxnet.co.uk/teletext/editor or https://edit.tf. These editors store the data in the url which is displayed in the browser address bar. All that is required is that the url is placed in a text file and that the text file is given a name that matches the required page number.
An Example:
Let’s say that the base page 101 has been allocated in which case the first frame to be created would probably be frame 101a. After completing the editing using either zxnet of edit.tf, simply place the resulting data (url) from the browser’s address bar into a text file called 101a.zxnet or 101a.edi.tf (depending on which editor you used). Place this file along with any others in the top level of the GIT repository. Once configured, Telstar will pick these up and publish them on Telstar.
Using JSON Frames
Telstar frames are actually defined using JSON data. The .zxnet and .edit.tf files described above, get converted to JSON by Telstar’s bulk uploader. Telstar JSON frame definitions can also be stored in the repository as .json files. This allows finer control over page routing, frame types, the content and so on. Full details of how the pages can be defined can be found in the Telstar wiki here https://github/johnnewcombe/telstar-2/wiki.
Deleting Frames
Telstar’s bulk uploader performs purging of data, for example, if frames 101a,101b,101c and 101d existed in Telstar and a bulk upload of frames 101a,101b was performed, frames 101c and 101d would be removed from the system. In other words, all ‘follow on’ frames not uploaded would be removed from the system. this extends to zero page routing frames, see below.
An example may be useful here. Imagine that its a newsworthy day and you have created, either manually or automatically, 10 news articles spanning 10 frames. Lets asssume these are shown on frame 101a to 101j. These get picked up by Telstars bulk uploader and all is good. The following day, not much happens and you only have four articles to be displayed on frames 101a to 101d. In this scenario you may well update yesterdays frames 101a to 101d and delete the rest of yesterdays news from your repository (101e to 101j). When Telstar’s bulk loader uploads 101a to 101d, it will automatically purge everything else from 101e onwards.
With purging on by default, it is important to recognise that, in the above scenario, frame 1010a is a ‘zero page’ route from 101z, so if there were 28 frames of news articles the first 26 would be on 101a to 101z the next would be 1010a and the final frame would 1010b. This means that in the example above with ten news frames on the first day and four articles the following day, in each case frame 1010a would have been purged had it existed.
Full details of Routing can be found here https://bitbucket.org/johnnewcombe/telstar-2/wiki.
Bulk upload was originally designed to automatically upload regular rss updates, rather than general hosting on Telstar. This means that while ‘purge’ deletion can be used to delete most pages, it currently can’t delete the ‘a’ frame e.g. in the above examples frame 101a can’t be deleted. The workaround, until the functionality is added, is to set the frame to invisible. See https://bitbucket.org/johnnewcombe/telstar-2/wiki.
Gateway and Response Frames
The uploading of Gateway and Response frames are disabled by default as they present a security risk. If you need a Gateway setting up, get in touch as this can usually be added in the main Gateway section (Page 6).
