Second Life Grid Glossary

A glossary of terms with specific meanings within the project, defined so that discussions can be concise and misunderstandings fewer. We also encourage you to take a look at the IEEE 1471 article on designing an effective system architecture which addresses all of the project goals.

Please note that this glossary is specific to the SL Architecture Working Group and is intended for use only within the context of Second Life. The definitions are not expressed in a generic manner, and should not be interpreted that way.

Agent

This is the user portion of the current notion of a SL agent. We may wish to name it user agent in distinction from the portion of the current notion of a SL agent which remains connected to the user's avatar, which one might call an avatar agent or "avatar proxy

An Agent is a software resource which represents some portion of a user in the virtual world. Agents are hosted in agent servers. An agent may cause an avatar to be instantiated on behalf of a user. An Agent mediates, for the user, by acting as the software endpoint in the system which invokes various services within the web at the user's direction, generally via the user's client.

for a tentative example of flows between Clients, Agents and Services, see AWG worked agent example

Agents:

• Mediate the user's message traffic
• Mediate the user's asset inventory
• Act as a focal point for the user's access to services in other domains
• Act as a focal point for the user's access to utilities

Agents do not:

• Store persistent assets (They are stored in asset servers)

Agents are not:

• the portion of the current SL agent which remains in the region simulators, this is the Avatar Delegate.

Architecture

An abstraction (or mental model) of the SL system which corresponds to its system design. It is revealed through architectural descriptions and multiple views (ADV).

Alternatively, the end product of a set of processes yielding a set of normative documents which define compliance to the architecture. This is not, inherently in opposition to the first definition as it captures the architecture at different points in its evolution.

Architectural descriptions and views (ADV)

Documents which describe (textually and/or graphically) how the various pieces of the SecondLife system fulfil their expected goals. More precisely, ADVs express in detail how the system architecture is conformant with the concerns expressed in viewpoints. Some examples:

For a message flow viewpoint, ADVs describe how system components interact with one another by describing their relations, protocols and message formats.

For a scalability-oriented viewpoint, ADVs describe the relevant system resource pools and their capacities, the flow paths and choke points, the bandwidth of links and access mechanisms, the means of expanding capacity, and the analysed scalability of key elements.

For a client capability viewpoint, ADVs ennumerate and detail the client-related capabilities, client-server capability negociation mechanisms and protocols, means of activating capability negociation, and client-side capability state transitions.

Asset

An entity which can be transferred from agent to agent or from agent to region or from region to agent. It can be something like an object, texture, sound, link, landmark, and so forth.

Architecturally, we destinguish between an asset and an asset reference:

• an asset is a blog of binary data, some (small) amount of meta data, a URL and a UUID. the meta data contains things like content-type.
• an asset reference contains a reference to the asset and properties such as permissions. asset references are inventory items.

Avatar

The representation of user in a region of virtual world space.

The avatar is the visual presence of the user within the virtual world. We distinguish this from the various data structures and software resources used to support the avatar, so that we can talk about how the avatar is projected into the virtual world, separate from the software components which perform that task.

Avatar Delegate

The endpoint within a region simulator that acts as delegate for the avatar. This is the software addressable, component of the system which allows other services, and the client to interact with the avatar's presence in the region simulator.

An Avatar Endpoint:

• Acts as the connection point between a client and the region simulator hosted avatar
• Acts as the locus for the avatar's sensing in the region simulator
• Follows the avatar's location within the region simulator

Note: This is the portion of the current agent, which remains in the region simulator when the agent components, such as inventory and IM management have been migrated to the agent, hosted on an agent server in the SL notion of an agent domain.

Avatar Delegate Child

the endpoint within a region simulator that acts as the delegate for an avatar in a adjacent region, for purposes of sensing, and being heard, within the adjacent region. This might also be thought of as the agent's camera, in the region.

An Avatar Delegate Child:

• Acts as the point at which an avatar senses activity in region adjacent to its current region
• Provides a connection between the user's client, and the region hosting the avatar delegate child.

Component

A logical composition that is proportional to a whole. In the domain architecture of the AWG, these compositions include viewpoints and views. In software and hardware, these include modules, units, and devices.

Domain

A partition of architectural resources, and services. A domain can be characterized by its membership and the set of properties that the members share. In Internet usage, a domain is commonly tied to DNS namespace, with the shared property being name resolution. In terms of our architectural structure, domains share a set of properties, and gain some benefit from this distinction.

The architecture may expose domain membership, and the properties which define the domain through a standard web service.

Examples of domains might include

• All the region servers supporting Linden Lab's mainland
• All the corporate hosted servers supporting XYZ Co's private islands. (Which might include Region, Asset, and Utility serviced specific to XYZ co.)
• All the servers and services within HostingCorps trusted firewall.

In each case, the partition permits the members to act differently with respect to each other, than members outside the partition.

To understand the rationale for this definition, see Domain rationale discussion.

Meta data

Meta data is data about data: it describes the data and its properties. In the architecture discussions we use meta data for assets.

Permissions

A kind of license digest that specifies what rights the creator of an asset grants to a user of that asset (or what rights she doesn't want to grant) [see also Protecting content in an open grid]

Presence

This term is used in two different ways:

• Loosely, the location or point of existence of an Agent in a sim, which is normally associated with the visible location of the agent's avatar. This is often used in phrases such as "The agent has a presence in a sim right after TP, and then rezzes its avatar at that location".
• The Service that manages the online/offline/busy/available/etc states of an Agent, and communicates the changes of state to interested parties, such as the Friends of the corresponding user. This use is compatible with the meaning of "Presence" in the Extensible Messaging and Presence Protocol (XMPP), as used in Jabber and Google Talk.

Refactored Composition

Refactored Composition refers to a technique to arrange the factors of a composition such that the composition is more orthogonal to a new model. This term, or like terms, is often mistakenly used in expression to just rewrite, remake, or recompose the factors, or lesser constituents, within the same model the composition already exists.

Region

Some space. It can have any form. It can be grouped together with other regions. It is part of a region domain.

Region Domain

Set of regions sharing one or more properties, permitting them to be grouped into a domain.

Examples of region domains might include:

• All of the regions forming a continent run by a service provider
• All of the regions hosted by the XYZ corporation
• All of the regions which support a new release of a physics engine

Resource

• [REST]: software entity, or stored value which can be addressed via a URL One basic design point of the architecture is that it follows RESTful web practices.

• [Scalability]: Any finite architectural component or property or behaviour that is subject to exhaustion or which can become a bottleneck to system performance. Resources are the primary focus in designing for scalability. Examples: client-server bandwidth, agent pool depth, database access mechanism, locks, transaction times, utilities, services.

Scalability

The ability of a system to grow effectively in a given dimension in proportion to the amount of resource or capacity provided. The given dimension is often associated with a related dimension. A specific system may attempt to be scaled by adding resources, but this is effective only if the system is scalable. Example: scalability in the number of avatars at an event, viewed against the size of the user population, in proportion to the hardware allocated.

Service

A Web Services invocable resource which performs some task on behalf of a region

Simulation (sim)

A computation over time that mimics real world events within a part of the virtual world.

Stakeholder

Anyone who has a technical viewpoint that impacts on AWG work on system architecture.

Non-technical viewpoints exist and have validity, but do not fall within the current scope.

Use case

A technique used to capture the requirements of a system or architecture. Use cases avoid technical jagon although this often depends on the scope and actors of the use case. Generally, the archtectural terms in this glosary are valid (i.e. Identity, Viewer, Service) while specific technical terms are not (C++, REST, XML). Detail of a AWG use case can vary:

• A brief use case consists of a few sentences summarizing the use case.
• A casual use case consists of a few paragraphs of text or a minimal template, summarizing the use case.
• A fully dressed use case is a formal document based on a detailed template with fields for various sections; and it is the most common understanding of the meaning of a use case.

For a more general understanding of use cases please see the Wikipedia article.

User

An person in control of an agent.

Utility

A Service, or collection of services which provides a utility which does not manifest as a region, agent or avatar within the virtual world. Examples: Currency, Identity, Asset Storage, Messaging, Presence, Topology Management.

Viewer

Currently, a monolithic client-side program which establishes communication with system servers and displays a visual image of the virtual world. It usually controls an agent represented by an avatar, eventually inside a region. As client programming evolves, the viewer per se may become only a client subprogram which deals with 3D rendering and UI handling exclusively, assisted by other subprograms.

Viewpoint

A set of related concerns about the architecture, and the representations or views used to describe the architecture to address those concerns. Examples: Client viewpoint, Client UI viewpoint, Functional viewpoint, REST Services viewpoint, Scalability viewpoint, Region Scalability viewpoint, Network viewpoint, Manpower viewpoint.

See Also

• Glossary
• Software and Systems Engineering Vocabulary