Teletext Viewer for the World Wide Web

Report 1: Project Specification

Project Supervisor:
Ian Harries
Group Members
Nicola Hargreaves (Group Leader)
Ashok Katwala (Secretary)
James Bywater
Tom Coerkamp
Tom Forwood
Gavin Kinghall Were


Core Specification

Modular architecture
Working with a particular hardware choice, but designed for more than one.
Designed so that there can be one or more distributed teletext servers, data stores and page grabbers hosting the service, or these functions could be combined into one box.
Proxy available to run on the web server, where the teletext server and web server are distinct machines.
Including fastext
To provide, at least, the functionality available on a standard television.
Server cache
Storing all pages, updated by a simple algorithm, but identifying and storing all available subpages
Help system
To aid the user, particularly in explaining the features unavailable on a television.
Intelligent clickable page numbers
Thus we will attempt not to highlight simply every three digit number, for example £300million. but only those which could reasonably be page numbers.
Clickable URLs and email addresses
Making full use of the fact that the applet is running in a web browser.
URL addressing directly to pages
By going directly to a particular URL, a browser will be served with that page, on that channel.
Javaless functionality
Server generation of pages, in a useable form, with reasonable functionality. Builds on the URL addressing to provide a navigable version of the system for Javaless clients. It should be possible to provide this within the <APPLET> or <OBJECT> tag to give a version of the system which degrades seamlessly. This may be accomplished using clickable imagemaps or simple text.

Potential extensions to specification (ranked by desirability)

1. Keyword search
To improve user access to particular information.
1. Improved algorithm for server caching
Potentially dynamically based on gathered statistics.
1. Send the page by e-mail
By sending gif & html, as plain text or by reference (URL).
2. Bookmarking pages
Preferbly stored in a coherent user profile.
2. Session history
Allowing more web-like features such as forward and back.
2. User registration
Identified by cookie, or (if necessary) by login.
Gathering information from the browser, and storing preferences, bookmarks, etc will allow us to avoid asking stupid questions.
2. Application
More fully featured version distributed as application rather than applet; e.g. saving pages locally as Teletext.
3. Implementing on multiple servers
Demonstrating the usefulness of distributed systems through resilie
3. Collection & reporting of statistics
For example, most recently updated or popular pages.
Reporting to users, administrators or even the system itself, to provide better quality of service.
3. Multiple page grabs
For offline browsing
3. Printing pages
3. Local caching
For fastext and other desirable pages.
4. More Local caching
For previously viewed pages in this session.
4. Generating Teletext from templates
Would allow us to stay within a teletext environment, yet still display customised information to the user.
4. Implement alternative hardware option
5. Email notification of page changes
With email confirmation to ensure you can't irritate another user.

Intended Architecture

Diagram of intended

Proposed division of work

The principle division is between the client and server subgroups. The client group consists of gkw, tf and nh and the server group of tc, jb and ak. gkw will concentrate on the user interface, tf will be concerned with the client-side parsing and display of pages, nh will focus on server-client communication and the help system. ak will concentrate on the server-side production to provide Javaless-functionality, jb will concentrate on the Teletext Server and database, with tc looking at the Request Server and also the database (see Proposed Architecture).


Wednesday 27th OctoberFriday 5th NovemberComplete investigations and define data structures and interfaces.
Friday 5th NovemberWednesday 17th NovemberWorking up to internal demonstration of individual modules
Wednesday 17th NovemberWednesday 24th NovemberBasic functionality (inter-process communication; grabbing of pages and storing appropriately in database; simple rendering of pages in client) in place and interoperating
Wednesday 24th NovemberMonday 3rd JanuaryCompletion of all aspects of core specification and implement extended features
Monday 3rd JanuaryWednesday 5th JanuaryCompletion of code
Wednesday 5th JanuaryMonday 10th JanuaryWork on presentation and documentation
Monday 10th JanuaryFriday 21st JanuaryComplete documentation

During meetings, more milestones will be added as individuals are actioned to complete particular tasks.