|
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™
- it registers itself with the Venue OS which records the machine's name and IP number in the database, and
- 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.
![[Construction]](/images/construction.gif)
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.
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.
