Essentials:
   Home
   Definition
   Requirements
   Company

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

Venue OS:
   DBMS
   Communications
   Message Types
   Verbs
   Events
   Examples
   Venue Cash Card
   Broadcatch

* The History Behind Broadcatch - VOS

VOS - The Venue Operating System (1996)

(rev. 4.0 3/2/97)
The Venue OS - a localized, multi-media intensive instantiation of a personalized Broadcatch environment - was designed to support the Canter Technology Media Bar project in late 1996 and early 1997. Funding was never secured for this visionary project.

The three main sections of the Venue Operating System consist of:

  1. The VOS Daemon (specifically, its spawned client threads)
    • maintains connectivity with
      • a schema-oriented DBMS thread
      • a single client station
    • receives, interprets, formats and directs messages
      • to and from the DBMS
      • to and from the client machines
      • to the logger
    Additionally, in the near future the VOS will also
    • communicate with a Broadcatch engine
    • accept Show Control input from human operators,
    • interface with the ARTI physical systems interface, and
    • (what else?)
  2. The Database (DBMS) (and its spawned schema threads) which
    • stores all the data used by all the schemas in a venue,
    • supplies shared content for the applications,
    • provides persistent storage for e.g. customer (avatar) preferences,
    • provides caching of frequently used tables, such as the Station Table and cppAll, and
    • maintains customer usage and account records (see also: the Venue Cash Card)
  3. A Base Network Object which enables
    • generalized communications between applications and the VOS/DBMS (see prototypes),
    • simple and complex queries (see message types),
    • asynchronous notifier-style messages from the VOS to the client station (see verbs & events),
    • (what else?)

Order of operations:

  1. The VOS and DBMS processes are started on a server machine
  2. Each sets up a TCP/IP socket listener on a well-know port
  3. A client machine (Art - bottom left) makes a connection request to the VOS listener passing requested database schema name and machine ID
  4. The VOS listener spawns a child thread (essentially a copy of itself)
  5. The VOS thread requests a schema-oriented connection from the DBMS parent listener
  6. The DBMS listener checks to see if there is already a thread started for the given schema
    • if not, then it spawns a DBMS thread for that schema
  7. A bi-directional communications line is accepted between the DBMS (schema) thread and the (client specific) VOS thread
  8. The VOS thread
    • requests a list of cached database versions from the DBMS thread
    • accepts a bi-directional stream socket connection with the client machine
    • notifies the client machine of the current database versions

VOS Process Flow:

[VOS Architecture]

Notes:

  • The VOS parent and child processes are lightweight and could be safely implemented in Java without a significant performance sacrifice
  • There is one VOS thread per client station but only one DBMS thread per active schema
  • Communications between the VOS thread and the client station will be via a client architecture independent message structure
  • The communications protocol between the VOS and DBMS threads is TBD
Page Created: Thursday, August 29, 1996
   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