The Role of AppService:
K2 AppService class diagram
AppService and the AppServerMgr object:
A service runs on the K2 called the "Grass Valley AppService". Its job is to provide clients with a way to control or retrieve information from the K2. AppService is implemented by a singleton AppServerMgr object on the K2 whose job is to create and manage AppServer objects for client applications. A client application first connects to the AppServerMgr, then asks the AppServerMgr to create an AppServer for it.
AppServer:
An AppServer is an object that is used for creating K2 subsystem objects. These subsystem objects allow you to control or get information from various sections of K2. For example, a MediaMgr object provides file information. A Control object provides ways to record or play clips, etc.
The AppServer keeps track of all objects that have been created. When an AppServer is closed, all of its subsystem objects are closed as well. If a client application would like to stop, but still keep all of its resources running, it can suspend the AppServer instead. This allows the application to start again later and reconnect to the same AppServer. This is useful if you want to keep a player or a recorder running even when the application is stopped.
K2 Subsystem objects:
These are the different types of subsystem objects that an AppServer can create:
- AppServerLog - for writing messages to the K2's log
- ChanStatus - for getting status information about channels
- ConfigMgr - for getting configuration information from the K2
- Control - for controlling players and recorders
- DVCapture - for capturing material from a DV source
- Editor - for editting assets
- MediaMgr - for getting information about volumes, bins, and assets
- Status - for getting status information from the K2
- TransferQueue - for transferring assets between K2s, M-Series, and Profiles
