This document is http://videdot.com/old/design.html
This document should be read in conjunction with the requirements overview and outsourcing document.
The overall approach of videdot is one of structuring the solution to the problem by solving a number of much smaller problems with clear interfaces between them. These parts are most clearly described in the Outsourcing Report. This, instead, covers the reasoning behind the design choices made.
The key decisions made to date fall in to a number of categories:
BeOS is an operating system developed by Be, inc. which runs on x86 and PowerPPC processors. It:
BeIA is Be's 'Internet Appliance solution'. It has the same core as BeOS, and is being pitched as a working, usable solution which is ready now, supporting the main standards required of say, a webpad or networked home entertainment appliance - Personal Java, Real Media, Flash and broad Web standards using Opera. Since BeIA uses the same API as 'vanilla' BeOS, developing for it doesn't change the code substantially, just means considering the different requirements given how the device will be used.
A more complete description of these features is in Appendix A of the Outsourcing Report.
In creating something to replace people's video recorder it makes sense to actually fit the same niche. Furthermore, a number of suppliers now exist to fashion standard PC-clone-bank parts into small, thin, quiet cases. With this, the ever-falling price of the necessary components for a PC, and the wisdom of dedicating a box to something which will likely benefit from stealing all of the processing power, it makes it quite viable to build a black box solution.
By providing a suitable interface, any remote client (suitably authenticated) can connect to the videdot box to control it anyway. With all that said, the code written should be as happy running under BeOS on a desktop machine as on a black-box arrangement. The difference is one of focus, particularly in designing the interface, to appeal to non-technical people, using interface elements which make sense, without - in general - relying on the learnt behaviour people have from using computers, instead making it more like an appliance, with simple - but powerful controls.
While broadband connectivity for all is continually promised as being just around the corner, relying on this for routine video, without building a substantial architecture á la HomeChoice, is somewhat questionable. videdot is designed to fit now and extend happily into a world with bigger, fatter network connections.
As discussed in 'Making the best use of the network' below, videdot does not ignore the network. However, for present purposes it makes a lot of sense to record what you have available in your home, and then to find ways to share whatever information you want to with the rest of the world. You gain from having many, disparate, distributed nodes behaving independently. The system can, conceivably, support itself. Since peer-to-peer networking is being developed apace by others, it makes sense to allow for hooks into those networks from appliances. This way, videdot benefits from these developments, and avoids building a large architecture which must grow as the number of clients grow.
'Screen scraping' is the process of taking data intended for human eyes, and deconstructing it to infer structure to the content. Nowadays, it typically involves pulling apart websites which have the information you want and rewriting it in a more structured form. There are a number of problems with this approach.
Firstly, it is of questionable legality, most websites supplying listings explicitly decry this behaviour, and relying on it for a successful project could mean facing litigation. Secondly, it is utterly fragile. When whatever website changes its design, the screen scraper breaks. What is worse, it may be possible for it to break in such a way as it is not at all obvious the data now gathered is actually wrong.
This becomes all the more likely if the maintainers of the foreign website actually try to make screen scraping difficult. It would be quite simple to find ways to keep changing the information, without changing its presentation in a browser substantially, but making it fluid enough that the regular expressions governing the screen scraper generate utter nonsense.
This leads screen scrapers to run it against a number of websites, to try and gauge the reliability of the information. While this will improve the quality of the results, it also raises the amount of work required in maintaining all of the patterns used to match against each site.
For videdot, I have chosen to use a suitable listings source, supplied in a structured form. The Press Association have supplied some sample XML listings, and for a commercial application of this project, would be paid a suitable fee for supply of listings to the videdot clients. Other listings suppliers can be supported also, since the module which loads the listings into the filesystem is independent of the rest of the code. The only contract between the 'Fetcher' and the rest of videdot is the attributes laid down on the listings files.
Allowing for people with slim and fat network connections makes sense. This means allowing people to make the most of whatever they have access to. All videdot boxes will be fetching listings information from the network, the next obvious step is to share information about what programmes may be of interest. This may be by direct assertion, for example by informing your friend that they may like a certain programme; by inference, using the (anonymised) preferences of users to build an understanding of what a particular user may like given what they have watched (and perhaps asserted they like) in the past; or, more richly you could actually support communities of users, who build lists of good programmes, share suggestions, and start communicating between themselves. This is likely to be best supported using an appropriate website, and allowing for browsing from a videdot box.