Difference between revisions of "User:Lum Pfohl/LSL Goodies/HI-WA Occupancy Counter System"

From Second Life Wiki
Jump to navigation Jump to search
m (__NOTOC__)
Line 1: Line 1:
__NOTOC__
{| width="100%"
{| width="100%"
|-
|-
|valign="top"|
|valign="top"|
<FONT size="+2"><B>DETAILED REQUIREMENTS</B></FONT><BR/>
<FONT size="+2"><B>DETAILED REQUIREMENTS</B></FONT><BR/>__NOTOC__
<div id="box">
<div id="box">
==Help Island/Welcome Area Occupancy Counter System - Overview==
==Help Island/Welcome Area Occupancy Counter System - Overview==
Line 11: Line 10:


===Statement of Business Need===
===Statement of Business Need===
The information described above, when extended to discerning Second Life Mentors from New Residents, can be useful in determining effectiveness of Second Life Mentoring and Greeter programs as well as helping Mentors decide where to go to help New Residents.
The information described above, when expanded to distinguishing Second Life Mentors from New Residents, can be useful in determining effectiveness of Second Life Mentoring Program and Greeter Program as well as helping Mentors decide where to offer help to New Residents.


===Project Scope===
===Project Scope===
This following list indicates the new functionality included as part of the enhancement package included in the HI-WA Occupancy Counter System:
This following list indicates the new functionality included as part of the enhancement package of the HI-WA Occupancy Counter System:
# Design, architect and build a system that will detect, count and tally the occupancy levels certain areas within Second Life.
<P>&nbsp;1. Design, architect and build a system that will detect, count and tally the occupancy levels in certain areas within Second Life.</P>
# The areas for consideration include, but are not limited to: Orientation Islands (all), Help Islands (all) and Welcome Areas / Infohubs.
<P>&nbsp;2. The areas for consideration include, but are not limited to:  
# Allow for a number of clients which can poll for this information and utilize it in various ways.  Some such methods include, but are not limited to, Text Displays, HUDs, Database/Warehousing Server, other Occupancy Counter Systems.
:* Orientation Islands (all)
:* Help Islands (all)
:* Welcome Areas / Infohubs.</P>
<P>&nbsp;3. Allow for a number of clients which can poll for this information and utilize it in various ways.  Some such methods include, but are not limited to:
:* Text Displays  
:* HUDs
:* Database/Warehousing Server
:* Other Occupancy Counter Systems.</P>


===Project Out Of Scope===
===Project Out Of Scope===
The following is a list of items that are specifically excluded from this enhancement:
The following is a list of items that are specifically excluded from this enhancement:
# Real-time info.
<P>&nbsp;1. Real-time info.</P>
# Resident names and personal metrics.
<P>&nbsp;2. Resident names and personal metrics.</P>
# Data warehousing capabilities although external systems (under a separate project) can interface to it to gather limited info.
<P>&nbsp;3. Data warehousing capabilities although external systems (under a separate project) can interface to it to gather limited info.</P>
</div></div>
</div></div>
<div id="box">
<div id="box">
==User Characteristics==
==User Characteristics==
<div style="padding: 0.5em">
<div style="padding: 0.5em">
The Second Life Mentor group has several thousand members whose focus is on locating areas where New Residents require basic help.  The Mentors are at least 6 months old (by the calendar from their rez-date), and possess a certain level know knowledge of the intricacies of Second Life, the usage of certain basic tools and widgets available to them, to complete their business tasks.  The Second Life Mentor group also have a number of Linden Lab employees (for example: VTeam) whose focus is on the effectiveness of the Second Life Mentor Program and the retention of New Residents as they enter Second Life.  Users generally do not have extensive technical expertise.  Nonetheless, Users are knowledgeable regarding their business tasks.  Consequently, the pool of Users overall is considered to be sophisticated.
The Second Life Mentor group has several thousand members whose focus is on locating areas where New Residents require basic help.  The Mentors are at least 6 months old (based on calendar days from their rez-date), and possess a certain level of knowledge of the intricacies of Second Life, the usage of certain basic tools and widgets available to them, in order to complete their business tasks.  The Second Life Mentor group also have a number of Linden Lab employees (for example: VTeam) whose focus is on the effectiveness of the Second Life Mentor Program and the retention of New Residents as they enter Second Life.  Users generally do not have extensive technical expertise.  Nonetheless, Users are knowledgeable regarding their business tasks.  Consequently, the overall pool of Users is considered to be sophisticated.
</div></div>
</div></div>
<div id="box">
<div id="box">
==Specific Requirements==
==Specific Requirements==
<div style="padding: 0.5em">
<div style="padding: 0.5em">
# Design, architect and build a system that will detect, count and tally the occupancy levels certain areas within Second Life.
{| width="100%"
# The areas for consideration include, but are not limited to: Orientation Islands (all), Help Islands (all) and Welcome Areas / Infohubs.
|-
# Allow for a number of clients which can poll for this information and utilize it in various ways.  Some such methods include, but are not limited to, Text Displays, HUDs, Database/Warehousing Server, other Occupancy Counter Systems.
|valign="top" bgcolor="#CCCCCC"|
# The system must be able to operate entirely in-world and not be dependent on any external systems for information/message routing, configurations.   
Reqt. ID#
# The system must continue to be operable and maintainable beyond the creator's lifespan.
|valign="top" bgcolor="#CCCCCC"|
# The system must be able to perform under potentially hostile conditions.  For example: Parcels/Sims with '''No Script,''' '''No Build,''' '''No Object Entry,''' '''2 minute auto-return,''' etc.
Description
# The system must provide a basic mechanism for utilizing the collected information at a "personal" levelFor example: a personal HUD that will receive information, parse and display it in a manner meaningful to the end-user.
|valign="top" bgcolor="#CCCCCC"|
# The system must be scalable to handle requests from potentially several thousand Users.
Type
# The system must provide a mechanism to alert the User if an update is available, and where possible to automatically deliver such updates to the Users.
|valign="top" bgcolor="#CCCCCC"|
# The system must be easy to maintain.
Priority
# The system must be well-documented.
|valign="top" bgcolor="#CCCCCC"|
# The system must operate autonomously.
Companions
# The system must be easy to use by the User base (as described in the previous section).
|-
|colspan="5" bgcolor="#DDDDDD"|
1. System Architecture
|-
|valign="top"|
REQT-1.01
|valign="top"|
Design, architect and build a system that will detect, count and tally the occupancy levels in certain areas within Second Life.
|valign="top"|
Logical
|valign="top"|
Mandatory
|valign="top"|
N/A
|-
|valign="top"|
REQT-1.02
|valign="top"|
The areas for consideration include, but are not limited to: Orientation Islands (all), Help Islands (all) and Welcome Areas / Infohubs.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.03
|valign="top"|
Allow for a number of clients which can poll for this information and utilize it in various ways.  Some such methods include, but are not limited to, Text Displays, HUDs, Database/Warehousing Server, other Occupancy Counter Systems.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.04
|valign="top"|
The system must be able to operate entirely in-world and not be dependent on any external systems for information/message routing, configurations.   
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.05
|valign="top"|
The system must continue to be operable and maintainable beyond the creator's support period or avatar lifespan.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.06
|valign="top"|
The system must be able to perform under potentially hostile conditions.  For example: Parcels/Sims with '''No Script,''' '''No Build,''' '''No Object Entry,''' '''2 minute auto-return,''' etc.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.07
|valign="top"|
The system must be scalable to handle requests from a few to potentially several thousand Users.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.08
|valign="top"|
The system must operate autonomously.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.09
|valign="top"|
The system must be fault-tolerant.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
2. Collection Server
|-
|valign="top"|
REQT-2.01
|valign="top"|
The collection server must be able to accommodate all inbound update metrics from remote sensors at a reasonable update rate.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-2.02
|valign="top"|
The collection server must be able to produce, upon request, all information in a format that permits transmission of said payload in a compact manner for rapid delivery.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-2.03
|valign="top"|
The collection server must be able to operate in a mode that is fault-tolerant.  That is, temporary disruption of service to the the collection server or the simulator that is carrying the collection server, should not result in a stoppage of the entire system.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-2.04
|valign="top"|
The collection server must be able to provide trans-version service.  That is, as parts of the system is being upgraded, the server must be able to parse incoming data as well as respond to requests for outbound data to different version endpoints.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
3. Relay Servers
|-
|valign="top"|
REQT-3.01
|valign="top"|
The relay servers must be able to accommodate all information in a format that permits transmission of said payload in a compact manner for rapid delivery.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-3.02
|valign="top"|
The relay servers must be able to operate in a mode that is fault-tolerant.  That is, temporary disruption of service to the the relay servers or the simulator that is carrying the relay servers, should not result in a stoppage of the entire system.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-3.03
|valign="top"|
The relay servers must have as "fresh" information as possible without placing undue load on the collection server, such that it minimizes the stale data.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-3.04
|valign="top"|
The relay servers must be able to provide trans-version service.  That is, as parts of the system is being upgraded, the server must be able to parse incoming data as well as respond to requests for outbound data to different version endpoints.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-3.05
|valign="top"|
The relay servers must be able to recognize data requests from endpoints, and their client versions.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-3.06
|valign="top"|
The relay server must be able to provide notification to endpoint devices that require updated version in order continue functioning normally.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-3.07
|valign="top"|
The relay server must be able to provide an updated endpoint device to the requesting agent, where it is technically feasible, and not doing so will result in non-deterministic behavior.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
4. Sensors
|-
|valign="top"|
REQT-4.01
|valign="top"|
The sensors must take measurements of the number of avatars/agents in a given locale and relay the information to the collection server on a periodic basis.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-4.02
|valign="top"|
The sensors must be able to distinguish more than 16 avatar/agents in a given locale (a hard limit in LSL).
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-4.03
|valign="top"|
The sensors must be able to distinguish detected avatar/agents in the same group as the sensor is set to from avatar/agents not in the same group as the sensor and report those two metrics separately to the collection server.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-4.04
|valign="top"|
The sensors must employ techniques to ensure their longevity in the parcel/sims they occupy.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-4.05
|valign="top"|
The sensors must be non-intrusive and not detectable by residents as possible.  That is, they should not be seen, or felt or otherwise interact with the environment or avatar/agents on the parcel/sim.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
5. Endpoint Devices
|-
|colspan="5" bgcolor="#EEEEEE"|
5a. Personal HUD Device
|-
|valign="top"|
REQT-5a.01
|valign="top"|
The personal HUD device must be easy to use.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-5a.02
|valign="top"|
The personal HUD device must not occupy valuable screen space/
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-5a.03
|valign="top"|
The personal HUD device must be able to operate in no-script regions.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-5a.04
|valign="top"|
The personal HUD device must employ techniques to not overload the system with repeated or frivolous requests.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-5a.05
|valign="top"|
The personal HUD device must display the data received from the Relay Server in a manner that is meaningful to the User.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#EEEEEE"|
5b. Text Display Device
|-
|valign="top"|
REQT-5b.01
|valign="top"|
The text display device must be able to operate autonomously.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-5b.02
|valign="top"|
The text display device must employ techniques to not overload the system with repeated or frivolous requests.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-5b.03
|valign="top"|
The text display device must display the data received from the Relay Server in a manner that is meaningful to the User.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
6. Product Distribution System
|-
|valign="top"|
REQT-6.01
|valign="top"|
The product distribution system must be set in a conspicuous place, and be easy to find.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-6.02
|valign="top"|
The product distribution system must dispense the latest available endpoint device.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-6.03
|valign="top"|
The product distribution system must be able to receive incoming requests from relay servers to dispense the latest available endpoint device to the avatar key provided.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
7. Documentation and Maintenance
|-
|valign="top"|
REQT-7.01
|valign="top"|
The HI/WA System must be well documented.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-7.02
|valign="top"|
The source code for all of the system components must be published and available.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-7.03
|valign="top"|
The source code must be well-documented for others to be able to understand the flow.  "Self-documenting code" should be discouraged.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|}
</div></div>
</div></div>
[[User:Lum Pfohl|Lum Pfohl]] 13:58, 30 August 2008 (PST)
[[User:Lum Pfohl|Lum Pfohl]] 13:58, 30 August 2008 (PST)

Revision as of 18:45, 30 August 2008

DETAILED REQUIREMENTS

Help Island/Welcome Area Occupancy Counter System - Overview

Background

This is a system of scripts, sensors and servers designed to sense, collect, report and disseminate information on the occupancy levels of Orientation Islands, Help Islands, Welcome Areas and Infohubs.

Statement of Business Need

The information described above, when expanded to distinguishing Second Life Mentors from New Residents, can be useful in determining effectiveness of Second Life Mentoring Program and Greeter Program as well as helping Mentors decide where to offer help to New Residents.

Project Scope

This following list indicates the new functionality included as part of the enhancement package of the HI-WA Occupancy Counter System:

 1. Design, architect and build a system that will detect, count and tally the occupancy levels in certain areas within Second Life.

 2. The areas for consideration include, but are not limited to:

  • Orientation Islands (all)
  • Help Islands (all)
  • Welcome Areas / Infohubs.

 3. Allow for a number of clients which can poll for this information and utilize it in various ways. Some such methods include, but are not limited to:

  • Text Displays
  • HUDs
  • Database/Warehousing Server
  • Other Occupancy Counter Systems.

Project Out Of Scope

The following is a list of items that are specifically excluded from this enhancement:

 1. Real-time info.

 2. Resident names and personal metrics.

 3. Data warehousing capabilities although external systems (under a separate project) can interface to it to gather limited info.

User Characteristics

The Second Life Mentor group has several thousand members whose focus is on locating areas where New Residents require basic help. The Mentors are at least 6 months old (based on calendar days from their rez-date), and possess a certain level of knowledge of the intricacies of Second Life, the usage of certain basic tools and widgets available to them, in order to complete their business tasks. The Second Life Mentor group also have a number of Linden Lab employees (for example: VTeam) whose focus is on the effectiveness of the Second Life Mentor Program and the retention of New Residents as they enter Second Life. Users generally do not have extensive technical expertise. Nonetheless, Users are knowledgeable regarding their business tasks. Consequently, the overall pool of Users is considered to be sophisticated.

Specific Requirements

Reqt. ID#

Description

Type

Priority

Companions

1. System Architecture

REQT-1.01

Design, architect and build a system that will detect, count and tally the occupancy levels in certain areas within Second Life.

Logical

Mandatory

N/A

REQT-1.02

The areas for consideration include, but are not limited to: Orientation Islands (all), Help Islands (all) and Welcome Areas / Infohubs.

Type

Priority

Companions

REQT-1.03

Allow for a number of clients which can poll for this information and utilize it in various ways. Some such methods include, but are not limited to, Text Displays, HUDs, Database/Warehousing Server, other Occupancy Counter Systems.

Type

Priority

Companions

REQT-1.04

The system must be able to operate entirely in-world and not be dependent on any external systems for information/message routing, configurations.

Type

Priority

Companions

REQT-1.05

The system must continue to be operable and maintainable beyond the creator's support period or avatar lifespan.

Type

Priority

Companions

REQT-1.06

The system must be able to perform under potentially hostile conditions. For example: Parcels/Sims with No Script, No Build, No Object Entry, 2 minute auto-return, etc.

Type

Priority

Companions

REQT-1.07

The system must be scalable to handle requests from a few to potentially several thousand Users.

Type

Priority

Companions

REQT-1.08

The system must operate autonomously.

Type

Priority

Companions

REQT-1.09

The system must be fault-tolerant.

Type

Priority

Companions

2. Collection Server

REQT-2.01

The collection server must be able to accommodate all inbound update metrics from remote sensors at a reasonable update rate.

Type

Priority

Companions

REQT-2.02

The collection server must be able to produce, upon request, all information in a format that permits transmission of said payload in a compact manner for rapid delivery.

Type

Priority

Companions

REQT-2.03

The collection server must be able to operate in a mode that is fault-tolerant. That is, temporary disruption of service to the the collection server or the simulator that is carrying the collection server, should not result in a stoppage of the entire system.

Type

Priority

Companions

REQT-2.04

The collection server must be able to provide trans-version service. That is, as parts of the system is being upgraded, the server must be able to parse incoming data as well as respond to requests for outbound data to different version endpoints.

Type

Priority

Companions

3. Relay Servers

REQT-3.01

The relay servers must be able to accommodate all information in a format that permits transmission of said payload in a compact manner for rapid delivery.

Type

Priority

Companions

REQT-3.02

The relay servers must be able to operate in a mode that is fault-tolerant. That is, temporary disruption of service to the the relay servers or the simulator that is carrying the relay servers, should not result in a stoppage of the entire system.

Type

Priority

Companions

REQT-3.03

The relay servers must have as "fresh" information as possible without placing undue load on the collection server, such that it minimizes the stale data.

Type

Priority

Companions

REQT-3.04

The relay servers must be able to provide trans-version service. That is, as parts of the system is being upgraded, the server must be able to parse incoming data as well as respond to requests for outbound data to different version endpoints.

Type

Priority

Companions

REQT-3.05

The relay servers must be able to recognize data requests from endpoints, and their client versions.

Type

Priority

Companions

REQT-3.06

The relay server must be able to provide notification to endpoint devices that require updated version in order continue functioning normally.

Type

Priority

Companions

REQT-3.07

The relay server must be able to provide an updated endpoint device to the requesting agent, where it is technically feasible, and not doing so will result in non-deterministic behavior.

Type

Priority

Companions

4. Sensors

REQT-4.01

The sensors must take measurements of the number of avatars/agents in a given locale and relay the information to the collection server on a periodic basis.

Type

Priority

Companions

REQT-4.02

The sensors must be able to distinguish more than 16 avatar/agents in a given locale (a hard limit in LSL).

Type

Priority

Companions

REQT-4.03

The sensors must be able to distinguish detected avatar/agents in the same group as the sensor is set to from avatar/agents not in the same group as the sensor and report those two metrics separately to the collection server.

Type

Priority

Companions

REQT-4.04

The sensors must employ techniques to ensure their longevity in the parcel/sims they occupy.

Type

Priority

Companions

REQT-4.05

The sensors must be non-intrusive and not detectable by residents as possible. That is, they should not be seen, or felt or otherwise interact with the environment or avatar/agents on the parcel/sim.

Type

Priority

Companions

5. Endpoint Devices

5a. Personal HUD Device

REQT-5a.01

The personal HUD device must be easy to use.

Type

Priority

Companions

REQT-5a.02

The personal HUD device must not occupy valuable screen space/

Type

Priority

Companions

REQT-5a.03

The personal HUD device must be able to operate in no-script regions.

Type

Priority

Companions

REQT-5a.04

The personal HUD device must employ techniques to not overload the system with repeated or frivolous requests.

Type

Priority

Companions

REQT-5a.05

The personal HUD device must display the data received from the Relay Server in a manner that is meaningful to the User.

Type

Priority

Companions

5b. Text Display Device

REQT-5b.01

The text display device must be able to operate autonomously.

Type

Priority

Companions

REQT-5b.02

The text display device must employ techniques to not overload the system with repeated or frivolous requests.

Type

Priority

Companions

REQT-5b.03

The text display device must display the data received from the Relay Server in a manner that is meaningful to the User.

Type

Priority

Companions

6. Product Distribution System

REQT-6.01

The product distribution system must be set in a conspicuous place, and be easy to find.

Type

Priority

Companions

REQT-6.02

The product distribution system must dispense the latest available endpoint device.

Type

Priority

Companions

REQT-6.03

The product distribution system must be able to receive incoming requests from relay servers to dispense the latest available endpoint device to the avatar key provided.

Type

Priority

Companions

7. Documentation and Maintenance

REQT-7.01

The HI/WA System must be well documented.

Type

Priority

Companions

REQT-7.02

The source code for all of the system components must be published and available.

Type

Priority

Companions

REQT-7.03

The source code must be well-documented for others to be able to understand the flow. "Self-documenting code" should be discouraged.

Type

Priority

Companions

Lum Pfohl 13:58, 30 August 2008 (PST)

Lum's Quick Links
LumSelfPortrait.jpg
Click to Enlarge


Related topics

edit