This document is http://videdot.com/old/outsource.html

At: /old/outsource.html

Outsourcing Report

By Ashok Argent-Katwala <ash@videdot.com>

Status: Old

See explanation.

Covering project background, specification for implementation and test cases.

The aim of videdot is to provide a black box appliance video recorder, using the network to collect listings, support collaboration and enable remote access.

Specification

This project is to be implemented on top of BeOS, making heavy use of its threading, messaging and indexed, attributed filesystem. For more information about BeOS, see the Background Section, and also the web resources listed there. A proper implementation of this specification will need to follow the guidelines outlined there.

For a broader discussion of the reasoning behind choosing the particular design here, please see the write-up at http://videdot.com/design.html. For an the underlying requirements consult http://videdot.com/requirements.html. So, when the reasoning behind a choice made here is not clear, they should be consulted.

Overview

The individual parts of the system are specified below, in the Parts section. However, to put that in context it is useful to first look at the intended feature set, followed by the chosen architecture.

The overall aim of the system is to provide the right features, and the system this specification describes is designed to support a number of desirable features as well as a core which must be implemented. A successful implementation will provide for everything in the core and a selection of other elements.

Core features

The very basic needs are to:

For a functional system these features are essential:

Select Channels
Choosing the available channels for a particular installation in a friendly manner. Making this friendly means avoiding presenting long lists of all possible channels whenever possible. A user should be able to choose their television region, cable or satellite package.
Fetch listings for chosen channels
From an appropriate structured source, quite probably XML, unpacking the data and storing it in attributed indexed files in the filesystem. Information should not be discarded at this time, unless it is absolutely useless.
Search in listings and recordings
Preferably using incremental search, so that while the search term is typed, more refined results are displayed progressively. Using this method depends the efficiency with which this can be achieved with queries on the BFS filesystem, and also on successful usability testing.
Minimal exposed complexity
To work properly in the intended environment, it must be possible to operate and maintain the system without being exposed to the underlying complexity. It should have a similar level of complexity as other home entertainment devices. This does not preclude the notion of being able to access some form of advanced configuration, but it should not be necessary to do this in normal operation.
Variable quality recording
Offer a sensible abstraction to allow programmes to be recorded at various levels of quality, including audio only, but without exposing too much of the underlying resolution, codec and compression technical detail. Should have a means of showing the different quality levels to the user, and a mechanism for mapping particular quality levels to the underlying settings (hidden from the average user).

Desirable features

Set-top box support
Means supporting more than the handful of analogue terrestrial channels in the listings part of the application, and also finding a reliable mechanism for communicating with the set top box for changing channels. The architecture must support extending the system with channel-changing modules for different set-top boxes, and ideally at least one would be implemented.
'No Click Recording'
Schedule for recording anything which, from historical information, looks as though it will be of interest. At its simplest this could just mean scheduling every other occurrence of a recorded show to be recorded at a low priority. A smarter implementation would use aggregate information from other users collected by the Network Services module.
Storing subtitle information
And allowing searching of that information, taking the player to the appropriate part of the clip.
Displaying subtitles on playback would offer a substantial improvement over present VCRs.
Pause live TV
A very potent feature, Could be very hard, particularly in keeping up on modest hardware.
Offline storage
Retaining the metadata locally, so that powerful fast searching is still possible. Offering a usable means for storing large amount of data to a non-computer user means providing a greatly simplified interface to whatever storage medium is used. The user should not be forced to think in terms of files, but instead deal with recordings and programmes.

Network services are a key part of the videdot project, some of these features should be provided for:

Remote access
Web interface to monitor and control the videdot box remotely
If the web interface is suitably designed, it could also act as a local, networked interface to the box. For example, using a wireless web pad in the home.
Allow a remote user to send a message to the box to schedule a recording; this could allow friends to suggest a programme they think you may like, for example. Obviously there will be user authentication for this remote interface.
Requesting a neighbour to record a particular show
To cope with recording two things at the same time. This stops short of full peer-to-peer sharing.
Broad sharing of recordings
Tying in to an existing peer-to-peer network, through a centralised point where searching occurs, or with a bespoke scheme.

Architecture

Looking at a single installation of videdot, there are several major concurrent processes:

videdot : processes

The videdot application starts the whole procedure. On startup it ensures that all the other processes are running, if necessary. The videdot application runs full-screen on the device, and other functionality is accessed through its views. It periodically sends a message to the Fetcher background task to fetch listings from the Internet, which stores them in attributed files in the filesystem.

The layout of the full screen interface should have a central view with the present information, single-line status information at the top and bottom and appropriate toolbars off to one side. Usability testing is key to getting this display right, so it would be artificial to over-specify it here.

The Recorder background task queries the filesystem to find listed programmes which the videdot application has flagged to be recorded. It resolves any conflicts and records everything appropriately, and stores the recordings in the filesystem.

The Player is only invoked when the user chooses to watch a recording. It is started with the location of the recording to be watched, and the point in the file to begin watching from. The Stop/Play/Forward/Rewind/Pause controls are still presented by the videdot application, so that keyboard and infra-red controls can be handled in one place. This control information is passed through to the Player using messages.

The other substantial part of this project is to support collaboration over the network. Consider two separate videdot installations both connected to the Internet:

videdot : network

Each videdot installation collects its listings from a Listings Server somewhere on the network. To support different regions and localities properly it makes sense to allow for a number of distributed Listings Servers, so a pair of clients may connect to different Listings Servers.

Thus a scheme for identifying a particular programme between two different videdot installations, which may be using different Listings Servers, is desirable. It is suggested that identifying based on channel and time, and failing to identify some pairs (for example, where a channel has some regional variations) as the same programme is sufficient. However, when collaborating it will often be necessary to search the remote box and find its identifier for a particular show. By restricting this query appropriately, the programme should be found in all sensible cases.

A Collaboration Server has a number of roles. It could:

Exactly what it supports depends on the particular form of sharing that the project implements. The only hard requirement of this specification is that collaboration is supported, at the very least in terms of aggregated suggestions. Leaving more than that unspecified but guided here is reasonable for such an extension to the core specification.

So the two videdot could be collaborating both directly or indirectly. Sharing behaviour (suitably anonymised) and potentially making requests of one another to record particular programmes, or to send a particular recording.

Interface

All aspects of the interface should be designed with the target user in mind. This is not a typical home computer user, but instead a more general audience. The interface should be of the sort expected of other sophisticated entertainment devices -- televisions, set-top boxes and such like.

The most strict requirement this brings in is keeping things simple and hiding much of the detail of some operations. The particulars of which codec, compression rate and resolution, for example, should not be exposed to the general user.

The interface should be usable with just a point and click interface, using only a keyboard or with both. The point and click interface could be with a touch screen, mouse or trackball, so this should be accounted for when designing the user interface elements, particularly to avoid having small buttons to press. Supporting a (possibly limited) keyboard should allow support for infra-red remote controls, with the IR signals mapped to key presses with an appropriate BeOS add-on (for example Marco Nelissen's IRMan input server). Note that any such add-ons would have to be installed with minimal user intervention -- quite probably at installation time. Hiding such configuration and maintenance from the user is a key goal of this project. Be Inc. have recently announced a scheme for such things for their Internet Appliances. Management and Administration Platform (MAP) is specifically designed for such remote management of appliances. It may be appropriate to use this technology in this project, assuming friendly relations with Be Inc.

In general, for the interface to be usable it will need to make actions visible. A much longer exposition of this is available in Jef Raskin's The Humane Interface[1]. In short it means that what is possible in the interface can be seen as such and controls are labelled clearly, not signified by cryptic icons. This book also talks at length about avoiding mode errors, which for an interface aimed at a general audience is particularly important.

The interface designed will need to undergo usability testing, in order to ensure the final product satisfies these requirements. This is discusses in more detail in the Testing section below.

More discussion of interface matters is covered in the Background section below which looks at products offering comparable features, and thus what the target user is likely to expect in terms of interface.

Installation

Given a suitably equipped machine, with a supported TV card, graphics card, sufficient resources it should be possible to insert a bootable CD, which runs the installation program, asking a few simple questions (choose which drive to take over, location of listings server, network setup) to install the whole system in a black box fashion. It is also desirable to enable the installation of the necessary software on an existing BeOS machine, starting the videdot application as an ordinary desktop user, and automatically starting the background processes at boot time.

Installation must ensure that the necessary file types are set up with their attributes indexed. This cannot be left for a user to do, as in that case any files created before the indices would not be indexed properly. The installer should use the appropriate Be API calls, and not poke directly into the FileTypes stored in the filesystem. More information about this exact task was published in a Be Developer's Newsletter.

Maintenance

It should be possible to create new fields in the file types detailed below based on extra fields being available in the XML listings feed. This should not involve hefty user input, but there should be a panel within the Config to deal with removing attributes also.

A mechanism for updating other aspects is desirable. Particularly to manage what codecs are available through the system-wide Translators. Be's MAP, discussed above, is specifically designed for this task.

File Types

Much of the communication between different parts of the videdot is through (attributed) files stored in the local filesystem. A clear definition of what fields these may have is thus vital.

Listing

MIME Type: application/x-vnd.videdot.listing

All are Text as far as the FileTypes system is concerned, except VID:start and VID:end which are of type time. The fields are largely self-explanatory, except VID:record_pri and VID:record_auth, which detail programmes which should be recorded. To allow for resolving clashes for recording requests from different sources both a priority and who authorised the request are stored, and an intelligent decision can be made by Scheduler (see below).

VID:pluscode is useful to include, however given GemPlus' stance over making their codes available for computer-based applications and websites, it may well remain unused. Given the requirement to allow extensibility of the file types defined here it may be wise to leave this attribute out in the first instance, should the situation not improve. Time permitting a third party Pluscode generator could be used. However, this would not allow the most useful feature for this project, PDC, since the generated pluscode and that the broadcaster intends may vary.

Contents of file are empty or left for future development.

Recording

MIME Type: application/x-vnd.videdot.recording

Everything above, plus:

The file contents are structured text for storing subtitle information as: 


[timecode][reserved character][subtitle text]

e.g.: 


01:02:43.1[tab]Hello, good evening and welcome to[end of line]

The reserved character is an arbitrary choice, but one which must be settled for all purposes if clips are to be shared. In the absence of reasons to the contrary a tab character is chosen. The file should use unix-style end of line delimiters, which are the norm in BeOS. Unprintable characters can quite reasonably be left in and stripped on display, so long as the retained information has some reasonable meaning. In particular the system should not fail if there is a null in the incoming subtitle stream. For example with Teletext subtitles the coding of colour. In this format, the file is eminently greppable, which is a big bonus when searching for particular programmes later. Note that the time is measured from the beginning of the clip, not the time it was recorded at. The time is limited to HH:MM:SS.d, however this safely covers a recording up to a hundred hours to an accuracy of tenths of seconds, which is sufficient for the desired purposes. Whether or not subtitle information is actually available will depend on the source of the feed used. This part of the specification merely lays out how to store such information, see the Recorder description for more information on storing it, and the Player for display.

Documentation

This outsourcing is not just of code, but also of documentation. The code produced should follow a suitable coding convention, in line with the Be APIs. For example, OpenTracker (www.opentracker.org) has a coherent set of guidelines. The code should also use a self-documenting comment system, which generates interlinked web pages of the source. One such system is Doxygen (http://doxygen.org/).

The final report produced should follow the outline given in the Project Guidelines (http://www.doc.ic.ac.uk/~ajf/Teaching/Projects/Guidelines.html) and be produced in HTML and put on the videdot.com site. A well-formatted printed copy, bound in a departmental folder should be produced and handed in by the deadline, as detailed on the Project Guidelines page.

The CD produced should contain a full copy of all the HTML documents, as well as a postscript or PDF file from which a replica printed copy can be made. The source code and binaries should be included, and installation simplified by making the CD bootable, as outlined in the Installation section above.

Parts

There are a number of constituent parts to the videdot system. This section details what they are (a thread, a view), what their contract is with other parts of the system is, what messages they accept and what they expect of files stored in the filesystem.

Applications / Background Tasks

videdot Application
Is
Application
Purpose
Present full screen display on system start-up through which all other tasks are accomplished.
Ensures other supporting tasks are running, starts up interface, co-ordinates creation of the full screen view, and its children (as detailed below).
Talks to
All other parts
Receives
Status information from the boot process, since on startup it may need to behave differently depending on what was happening in the case of, for example, power loss.
Fetcher
Is
Background process
Purpose
  • Gets XML listings for user's channels
  • Explodes XML into (attributed) queryable files in the local file system
Talks to
FS, Preferences
Receives
Triggered by a message from interface or with a scheduled cron-like message dispatcher (consult Be's APIs).
Details
Creates files of type application/x-vnd.videdot.listing, with all available attributes on a user-defined volume.
The tree of files produced doesn't specifically matter, so long as each listing has a unique filename. All listings will be found based on querying their attributes, not their filenames. Some attention should be paid to splitting the files into directories to avoid overloading a particular directory. In particular there are known to be performance problems with having very large numbers of files in a single directory with BFS. The Dominic Giampolo book addresses this[2].
Pitfalls
Updating roster of attributes for application/x-vnd.videdot.listing as number of attributes increases (if XML feed offers more information than previously).
Recorder
Is
Background Process
Purpose
Makes recordings based on the files tagged by the Scheduler.
Talks to
Stores recording
Receives
Start / Stop / Set channel
Details
Must choose the quality appropriately, based on recording priority, what is known about the show, and available disk space. The codec used should be one of those installed on the machine, as selected or prioritised in the Config view.
Responsible for deleting files when needed, and must notify Status which redcordings are in line for deletion.
Pitfalls
Must be able to change channels gracefully. At the very least this must allow for tuning to different frequency on the TV card. Extensibility to allow controlling set-top boxes, etc. is highly desirable. At the very least a framework for changing channels for an arbitrary set-top box should be defined.
Player
Is
Application (invoked on demand)
Purpose
Invoked by the videdot application to play back recordings stored locally, including particular information that has been stored by the rest of videdot.
Talks to
FS, Control
Receives (messages from videdot application)
Play this file
Play this current recording (i.e. file still being written to)
Subtitles on/off (if available)
Interface on/off
Details
Possibilities include alpha blending control interface onto picture
May display subtitles in vision, or pass them to an external device. Position control, font, colours and other variables should either be derived from control codes in the subtitles or use appropriate (possibly configurable) defaults. Should use Be's font handling capabilities properly (i.e. the Bitstream font engine in BeOS) and handle everything in a size-sensitive manner.
Pitfalls
Complications of playing the current recording, and ensuring proper performance, should be investigated to test viability and implemented if feasible.

Message Loopers

Scheduler
Part Of
videdot application
Purpose
Populates FS with information for recording, with intended quality, etc.
Talks to
FS, Control, any other process which wants to schedule a recording.
Receives
Message to record this show (with this quality priority and authorisation)
Details
Should look to configured settings through Preferences for the mapping of given quality to concrete settings.
Pitfalls
Should it authenticate, or is the local box trusted? This is left as an implementational concern, as it depends on what network services the box is running as to the vulnerability of the box.
ScheduleBot
Part Of
Recorder
Purpose
Makes live query from information which Scheduler puts in FS
When starting a recording, creates a file of type application/x-vnd.videdot.recording, with information about the programme.
Annotates the attributed recording file with the location and format of the recording (as informed by Recorder).
Resolves conflicts (rules based, deciding what to record based on their priorities and possibly other information in the system). Ideally this would also include identifying shows that are repeated and such like. That will depend on whether the listings source makes such identification possible reliably.
Talks to
Recorder: to start, stop and change channel
Receives
Message with location and type of recording from Recorder
Details
Also clears space in the filesystem to ensure that the recording will fit into available space.
Pitfalls
Dealing with running out of file space gracefully. Must notify Status of what is in line to be deleted.
QueryBots
Part Of
videdot application
Purpose
There are (initially) four kinds of QueryBot, the implementation should allow for more to be added:
listings
Queries the file system for future programmes in the listings which match the given query
recordings
Queries stored recordings. By looking at the stored application/x-vnd.videdot.recording files, recordings can be found even where the movie itself has been taken offline.
net-peer
Send request over network to another videdot box (see network services) for stored recordings
net-server
Send request to a centralised server which processes requests
Talks to
As above
Receives
Message from Query with query term and parameters
Details
Conceivably this could be expanded to encompass querying other network sources and hooking in to file sharing schemes by adding appropriate QueryBots.
An example of the Delegation design pattern, if implemented properly.
In general, queries should be handled by building appropriate URIs with the query string. At the extreme, this could use any defined protocol, however only implementing HTTP is sufficient for many purposes.
Status
Part Of
videdot application
Purpose
Allows for a number of different status displays to register with this one server of information
Talks to
Any registered StatusDisplay
Receives
Messages of noteworthy status events from any part of system. Notably Player and ScheduleBot
Details
Should support at the very least a child view of Control to register itself as a StatusDisplay. Ideally would also support LCD panels as a separate StatusDisplay.
Preferences
Part Of
videdot application
Purpose
To dole out preferences from those stored in the FS through a simple interface, rather than cluttering a number of classes with common file-manipulation.
Talks to
Filesystem
Receives
Messages requesting particular named attributes.
Details
Should watch the settings file using BFS file notifcation, so that if the settings file is changed. In the absence of a valid settings file, or missing settings it should set an appropriate flag in Status and take a sensible default. where possible.

Views

Listings
Part Of
videdot application
Purpose
  • For the chosen channels, create the appropriate Channel views to display the listings.
  • Display listings in a ListingView, according to their attributes
  • Accept clicks on scroll buttons and pass through new times to Channel views.
  • Display summary information on the selected programme when notified by a Channel view.
Talks to
File system
Receives
Notification of selected programme from a particular Channel view.
Details
None
Channel
Part Of
videdot application
Purpose
  • Run a query (this channels, this period) and find the programmes from the file system
  • Display listings in a ListingView, according to their attributes
  • Accept clicks, highlight programme and pass back selected programme to Listings
Talks to
File system
Receives
Request for selected programmes
Query
Part Of
videdot application
Purpose
Aggregates results from a number of QueryBots and either delivers all-in-one-lump results, or piecewise as they arrive.
Talks to
Calls to come in from QueryView and somebody in Network Services
Creates QueryBots for required tasks, waits for messages from them.
Receives
Piecewise messages from individual QueryBots
Details
Should remain relatively lightweight
QueryResults
Part Of
videdot application
Purpose
Display the results incrementally.
Offer controls to desired functionality to schedule recording or play an existing recording.
Send a message to terminate the query cleanly should the user choose to play a recording.
Talks to
Query
Receives
(Piecewise) messages with updates to query results
Details
Must coordinate the view properly so that a selection remains selected on updates to the elements of the result set
Control
Part Of
videdot application
Purpose
Controling panel within the videdot application. Responsible for presenting options to the user, has children which represent the appropriate view at the time, be it Query, Listing, Channel, Config, etc. Also contains other views, to display the present state of the machine (time, date and information in a child implementing StatusDisplay).
Talks to
Sends messages to most other parts of videdot application.
Receives
User input
Details
Should offer the functionality described in the Testing Section through it's child views. These are best specified through a description of the behaviour and user stories than particularly enumerating every view.
Config
Part Of
videdot application
Purpose
To allow modification of install-time settings, channel selection and also some advanced options (encoding options and such like).
Talks to
Filesystem to store preferences (within ~/settings/ as per BeOS conventions).
Receives
Input from user
Details
Should allow:
  • Either prioritisation of codecs installed on system, some means of defining a number of quality levels or other means by which in cases of low disk space fallback options can be used. Basically to avoid exposing the end user to difficult questions giving precise definitions to meaningful phrases like 'high', medium', and 'low' quality, plus audio only.
  • Means of selecting available channels, preferably in a pleasant manner. That is reflecting the channel packs of different satellite or cable operators and terrestrial regions, rather than forcing individual selections from a very large number of channels. However, this may be a desirable fallback, should packages have changed recently.
  • Choose which device(s) listings and recordings are stored on (important to ensure queries are run against the appropriate volumes, and that attributes are indexed properly).
  • Update / delete indices for attributes. Update supported indices.
  • Define listings source URL
  • Configure privacy settings regarding remote aggregation information for suggestions.
  • Turn on/off servicing of remote requests for scheduling, programme information and recording sharing.

Other

Network Services
Is
Several background tasks, probably a thin web server running on the videdot box.
Purpose
Accept requests from remote videdot boxes' peer QueryBots, trigger events internally and return the relevant information to the questioner
Talks to
Other videdot installations, web browsers generally
Receives
HTTP GET requests, preferably on a configurable port.
Details
May wish to use the Robin Hood web server, with Scot Hacker's filesystem query hooks for BFS.
For file sharing may wish to hook into existing schemes for such matters. However for generic sharing of information it makes sense to deliver over HTTP based on simple requests. May wish to route through a central server, however this has obvious consequences in terms of failures.
Pitfalls
The UI must be kept simple, with the target audience in mind.
Server Facilities
Is
Remote Web Servers
Purpose
Listings Server as an XML feed of the listings data
Collaboration Server which provides aggregated information about what programmes are of interest to users and notifying them on request. This must follow appropriate privacy guidelines, and ensure that a user's personal habits are never released. This is probably best achieved by anonymising the individual installations, and only storing aggregate information on the server.
Talks to
Listings: Fetcher
Collaboration: videdot application
Receives
Listings: HTTP GET requests from Fetcher processes with the name of a channel.
Collaboration: Appropriate information about what shows the user is interested in, from which inferences can be made by the Collaboration Server.

Testing

Component testing is best achieved by sending messages to the various components. A testing harness should be written, which sends various messages - valid and invalid to individual parts listed above.

The focus on testing here, however, is on user stories, rather than component testing. By carrying out the following tasks suitable coverage testing can be achieved.

The tests are split into three parts:

There are also requirements in terms of response and usability. These are best specified tested using real users. The 'Normal operation' tests from above should be run again, with the focus ease of use of the interface, rather than whether or not the user manages to complete the tasks.

Installation and initial configuration

For several random selections of BeOS supported hardware, install and configure the setup.
Use bootable CD to choose a partition, set appropriate Network Services servers, configure BeOS networking and other options.
On subsequent startup the machine should be in the mode of normal operation.
Check that the indices are set-up properly for all of the 'VID:*' attributes.

Normal operation

Choose an appropriate set of channels for an installation
For whatever multi-channel environments are supported
Modify the chosen channels manually to cope with package changes from the powers that be
Preferably with the most sensible interface possible.
Switch on the display, find the programmes that are on now and in the next 2 hours
The first screen to come up should be displaying such a view, so at most the user will need to scroll along channels if they have a multi-channel set-up.
For a particular programme that can be seen in the multi-channel view, call up the extended programme information.
Is the information properly legible; if scrolling is needed to see everything is it clear how this is done?
From startup, call up those programmes starting in the next 12 hours which fit any of the user's defined search patterns.
Again, this should be available as a 'What's on' view of the data. It can reasonably use the query interface, but
For a particular show, set the box to record
Attention should be paid at time of recording. Does the interface make it clear that it is recording, without disturbing whatever operation is in progress at the time.
For a programme in a series, find when another episode is next on
'Find other episodes' should be an option in the selection specific panel.
Search for all episodes of 'Star Trek'
... modify the above search to exclude episodes of Voyager (Star Trek and not Voyager)
Should be able to refine search from the search results page.
... modify the search to only include episodes of Voyager (Star Trek and Voyager)
Should be able to modify the existing terms from the search results page.
All of the prior searches should have found any recordings as well as listings entries. (The default search pattern should be to find all local information.)
From the search results page, play back a recording
Recordings should be clearly marked, but still sorted by the chosen attribute. It should be possible to play straight from this view.
Find all available recordings, most recent first.
The results should display incrementally, and if a recording is played while the results are coming in, the query should terminate cleanly
Trigger a listings fetch manually
Continue using the box while the listings are fetched.
It should be clear but unobtrusive in the interface that listings are being collected.
Record a show in audio-only mode, then play it back
The player should keep a sensible interface on-screen during playback saying what is being played.
Playback a show with subtitles
Switch subtitles on and off periodically.
Perform an extended search on subtitle information
In the search results, the user should be presented with the matching line(s) for each result, and have controls to start playing the recording near those point(s).
Register user's interest in a particular show or series visible in the multi-channel view
Should offer confirmation and a link to a more detailed panel within Config to deal with preferences.
Test live pause facility (if implemented)
Pause, unpause, rewind, play and forward. Should display a sane picture all the time, and if fast forwarded up until the present time it should resume playing the live (or marginally delayed) signal.
Remote access
Web in to the box and re-run the tests above
Collaboration
Find recordings on a remote videdot installation.
Submit request for it to record a particular show
Test hooks into whatever file-sharing scheme is implemented by transferring recordings, with their attributes and ensuring they show up as any other recording does in searches.

Failures

While playing a recording, switch the power off on the box.
The box should restart into some reasonable, consistent state. This may be to play the recording from some point near the last known position, or (worse, but simpler) to the ordinary startup sequence.
While recording a programme, pull the plug on the box.
On restart, the query running for 'what should I record' should pick up again as soon as possible.
While downloading listings, pull the network connnection.
It should fail gracefully, with any message to the user displayed unobtrusively. If it fails consistantly (for several attempts), then the user should be made aware that something may be amiss with the network connection.

Background

Existing Products

There are a number of distinct areas of the project which relate to different existing products:

When considering all of these different devices it is important to focus on the appropriate target audience, and what they expect. The features presented by, for example, Hauppage's latest cards, which offer a Windows-based VCR, or listings applications and websites are less critical than, say, TiVo's offering. The product of this project is in many senses very similar to the TiVo or ReplayTV. There are elements of their design which depend very much on particular hardware. videdot is intended to be abstracted from much of this, by using Be's already implemented hardware support for many tasks and providing a suitable keyboard, mouse or equivalent control, together with remote network access, which is presently unavailable on commercial offerings.

Support of Videoplus+ codes is not vital to simple scheduling of recordings, as this is best achieved through the listings displayed anyway. However it is desirable in order to support Programme Delivery Control. This depends on a proper supply of codes, rather than using available code-generation algorithms, since the channels are using the proper codes for when the programme was first scheduled to be broadcast.

In interface terms, lessons should be learnt from the existing interfaces. In particular the users of videdot have very probably been using listings in magazines or newspapers. These have a relatively common layout, with vertical columns for channels. The videdot interface should follow this format, so long as it remains usable.

Video-on-Demand and EPGs offer the closest interface to much of what videdot needs. Although watching users attempt to use them can be painful. It may be worth conducting tests and surveys of other systems to find what particularly works and what fails.

About BeOS

BeOS is a closed source, but free (as in beer, rather than speech) operating system produced by Be Inc.. Its strengths are particularly in handling media well, with a lightweight, strongly multithreaded architecture, which has good message handling facilities. Another strength, which is of particular interest for this project is the Be File System (BFS), which is journaled, indexed and attributed. BeOS allows programs to run 'live queries', and be sent messages when there are changes.

Attributes and Queries

There are a number of attributed file systems -- SGI's XFS, reiserFS, ext3, IBM's JFS as well as BFS. The advantage to them, in general, is that files can be annotated with the appropriate information, and then found using queries, based on those annotations. The key difference with attributed filesystems is that they allow a relatively free-form of annotation, and can usually index the attributes to make searches over indexed attributes fast.

For example, BeOS ships with a People address book 'database', in which any person is a single empty file, with attributes describing their name, address, email, etc. You can then make searches over these files with anything that can query the file system. Thus, a mail client can just ask the file system for any person files anywhere on the file system where the email address is filled in, and present a list of those to the user how it pleases.

Moreover, BeOS supports live queries, which means that when running a query you can be notified of changes to anything within the set of results (new entries, entries that no longer satisfy the query). This is all based on message passing, rather than polling so is very efficient. It is the appropriate way to run the searches needed for this project.

More information about BFS, and the design decisions in making it, are given by its designer, Dominic Giampolo, in his book[2].

Threads

BeOS naturally creates a lot of threads, which are fortunately quite light. Creating a window, a view or a number of other constructs will implicitly create a thread. This pervasive multithreading means the system in general stays more responsive and is particularly useful on multi-processor machines.

What does this mean for developing under BeOS? In particular it means accessing resources properly, understanding the potential for deadlocks and synchronising access appropriately. Fortunately messages are well supported in BeOS, and are perfect for this task.

Messages

A number of objects in the Be API are derived from the BLooper class. Most notably BApplication and BWindow.

Key points to note about messaging are:

Views

The BView class is derived from BHandler, and so can be registered with a BLooper to process messages. Views are the principal means of displaying information to the user, and a number of useful view classes are defined in Be's API.

Much more useful information about these topics are covered in the Be Book, which is essential reading in order to implement anything in BeOS properly.

Useful BeOS resources:

References

[1]The Humane Interface
Jef Raskin
ISBN: 0201379376
[2]Practical File System Design with the Be File System
Dominic Giampolo
ISBN: 1558604979
: media without limits

[Login]

Ashok Argent-Katwala <ash@videdot.com>