Difference between revisions of "User:Lum Pfohl/LSL Goodies/HI-WA Occupancy Counter System"
m (__NOTOC__) |
|||
Line 1: | Line 1: | ||
{| 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 | 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 | This following list indicates the new functionality included as part of the enhancement package of the HI-WA Occupancy Counter System: | ||
<P> 1. Design, architect and build a system that will detect, count and tally the occupancy levels in certain areas within Second Life.</P> | |||
<P> 2. The areas for consideration include, but are not limited to: | |||
:* Orientation Islands (all) | |||
:* Help Islands (all) | |||
:* Welcome Areas / Infohubs.</P> | |||
<P> 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: | ||
<P> 1. Real-time info.</P> | |||
<P> 2. Resident names and personal metrics.</P> | |||
<P> 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 ( | 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%" | ||
|- | |||
|valign="top" bgcolor="#CCCCCC"| | |||
Reqt. ID# | |||
|valign="top" bgcolor="#CCCCCC"| | |||
Description | |||
|valign="top" bgcolor="#CCCCCC"| | |||
Type | |||
# The | |valign="top" bgcolor="#CCCCCC"| | ||
# The | Priority | ||
|valign="top" bgcolor="#CCCCCC"| | |||
# The | Companions | ||
# The system must be easy to | |- | ||
|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 - OverviewBackgroundThis 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 NeedThe 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 ScopeThis 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:
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:
Project Out Of ScopeThe 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 CharacteristicsThe 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
Lum Pfohl 13:58, 30 August 2008 (PST) |
|