Multi-Process Client VAG Glossary

List of common terms specific to the Multi-Process Client VAG -- draft:

Backend

The backend of the Multi-Process Client comprises all of the processes (called Facilities) that attach to the Facility Sockets of the frontend Mediator process.

Busy waiting

A very CPU-inefficient programming technique with only a few appropriate applications. When used outside of those areas it often results in poor performance, ineffective multitasking, a sluggish UI, and a CPU-starved operating system. See busy waiting for more details. The Multi-Process Client does not use busy waiting, but is instead event-driven.

Client Script

A client-side script (written in any scripting language) which runs within a Facility process. This scripting Facility process typically provides support for only one language binding environment or language VM, but generic scripting environments are also possible. Scripts run one at a time within their Facility process, unless the scripting language itself supports concurrency. By attaching multiple Facility processes to the Mediator, any number of Client Scripts can be run concurrently.

Facility

A Facility is a process in the backend of the Multi-Process Client. It attaches to the frontend Mediator process through a socket, and in this client-server communication the Facility process is the client, and the Mediator process is the server. Facilities normally communicate with each other through the Mediator, but are free to open higher-bandwidth channels of communication between themselves if required. Facilities are regular processes which execute concurrently under normal operating system multitasking. Modern multicore CPUs can be harnessed automatically if free cores are available.

Facility Optimization

The process by which the operation of a given Facility or of the client as a whole is raised in performance by creating higher-bandwidth communication channels between individual Facilities, or by physical merging of code from two or more Facilities. Facility Optimization should never be carried out until analysis and profiling/measurements show that performance constraints are not being met as a result of decoupling Facilities. Even then, the most extreme form of Facility Optimization should never be contemplated unless all else fails, because merging of Facilities reintroduces some of the failings and limitations of the monolithic client.

Facility Socket

In the current context, this term denotes an Internet socket which is used for communication between the Mediator process and one Facility process in the Multi-Process Client. The model also allows multiple socket channels to be created between the Mediator and any given Facility, if desired.

Frontend

The frontend of the Multi-Process Client comprises one process, the Mediator. This Mediator process operates as the "client" in client-server communications with the servers of virtual worlds. The Mediator process also provides multiple Facility Sockets and a Facilities API that operates over those sockets. The Mediator sets up listeners on the Facility Sockets. and therefore operates as a server in mediator-facility communications in which the facilities are the clients.

Viewer (deprecated)

Viewer is the original term used to denote the Second Life client. The SL client always performed so many duties in addition to mere viewing that viewer was never an accurate term for it. In the Multi-Process Client, world viewing is one of the functions implemented by Facility modules and may be spread out over several of them, so the term lacks specificity and is not used.

See Architecture Working Group Glossary for terms not defined here.