1981 - NewsPeek
     1983 - GIN
     1989 - SmarTV
     1992 - GenMagic
     1994 - CDML
     1994 - Social Ads
     1996 - Venue OS
     1999 - Lumeria

Venue OS:
   Message Types
   Venue Cash Card

* The History Behind Broadcatch - VOS

The VOS Data Base Management System (DBMS)

(rev 2.1, 10/7/96)

Application Database Connectivity

High level calls hide the internals of the database from the client applications, effectively making network database transactions independant of where the database is located on the net or even which brand of database is being used.

Local Cacheing

Illustra -- or any full-featured relational or object oriented DBMS -- is way too slow to have gating events from the MediaBar Client or other client applications. To speed things, pieces of the database will be cached locally (and transparently to the client applications) on the client stations. Such pieces might include:
  • the customer's state information (or Customer Pseudonym Profile (CPP))
  • the currently available food selections used by the Video Menu™ system, and
  • the currently available on-line avatars list used by e.g. Knock-Knock™ and perhaps MazeLove™
When each client station initializes (during boot or re-boot), it performs two network database transactions:
  1. it registers itself with the Venue OS which records the machine's name and IP number in the database, and
  2. it updates its local set of databases to be current by obtaining the complete list of available databases from the server ODBMS and then updating any whose version/seed numbers have changed.
Later, when a customer logs in (via a Venue Cash Card swipe) the server ODBMS will download to the local (booth) machine the customer's profile for local use (see Venue OS Flow of Control). Indeed, each station-based application may make requests to download portions of the database at any time. [Construction]

High-Level Database Commands

The goal of this design is to hide the actual inner workings of the remote database server connections and queries behind a set of high-level calls (an API) that is independant of such issues as
  • syncyronous or async communications,
  • remote query vs. locally cached data bases, and/or
  • the use of Illustra or some other central or distributed database.
In the long run, the most sensible way to go would be to have an asynch background cache management process performing synchronous calls to the remote database server maintaining local integrity so client apps can make fast synchronous calls to the "virtual" local (or shadow) database with no delays.

But, if the Mac still is to be treated as a single tasking machine, then the same high level design supports an implementation using asynch calls with callbacks.

How does the single tasking machine deal with serving its callbacks without polling and what about maintaining current state -- is it OK to have the display freeze for a moment (up to a second or two) as the data is accessed? (It probably won't be that bad at first -- not until we have maybe 20 machines running streaming viseo and/or audio and other simultaneous network & cpu resource-eating tasks.

The prototypes are still very rough. They are designed with synchronous calls that could either be called from the various apps or by a background cache maintenance proces on the Mac. I need to learn more about how callbacks are handled on the Mac station, from the database (and in Lingo?) before I can clearly present that side of things.

   Copyright © 1994-2007, Fen Labalme and CoMedia Consulting. All Rights Reserved.
Broadcatch is built on the OpenPrivacy Platform
I wish this
site were
Drupal Strategy and Consulting
This Site Supports Free Speech