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
Introduction
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
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).
Schedule
| Wednesday 27th October | Friday 5th November | Complete investigations and define data structures and interfaces. |
| Friday 5th November | Wednesday 17th November | Working up to internal demonstration of individual modules |
| Wednesday 17th November | Wednesday 24th November | Basic functionality (inter-process communication; grabbing of pages and storing appropriately in database; simple rendering of pages in client) in place and interoperating |
| Wednesday 24th November | Monday 3rd January | Completion of all aspects of core specification and implement extended features |
| Monday 3rd January | Wednesday 5th January | Completion of code |
| Wednesday 5th January | Monday 10th January | Work on presentation and documentation |
| Monday 10th January | Friday 21st January | Complete documentation |
During meetings, more milestones will be added as individuals are actioned to complete particular tasks.
